Ayaz Abdulla [Wed, 14 Apr 2010 01:49:51 +0000 (18:49 -0700)]
forcedeth: fix tx limit2 flag check
commit
5c659322a904a7cc0265e7b183372b9bdebec6db upstream.
This is a fix for bug 572201 @ bugs.debian.org
This patch fixes the TX_LIMIT feature flag. The previous logic check
for TX_LIMIT2 also took into account a device that only had TX_LIMIT
set.
Reported-by: Stephen Mulcahu <stephen.mulcahy@deri.org>
Reported-by: Ben Huchings <ben@decadent.org.uk>
Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Cc: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jean Delvare [Wed, 26 May 2010 13:05:11 +0000 (10:05 -0300)]
V4L/DVB: FusionHDTV: Use quick reads for I2C IR device probing
commit
806b07c29b711aaf90c81d2a19711607769f8246 upstream.
IR support on FusionHDTV cards is broken since kernel 2.6.31. One side
effect of the switch to the standard binding model for IR I2C devices
was to let i2c-core do the probing instead of the ir-kbd-i2c driver.
There is a slight difference between the two probe methods: i2c-core
uses 0-byte writes, while the ir-kbd-i2c was using 0-byte reads. As
some IR I2C devices only support reads, the new probe method fails to
detect them.
For now, revert to letting the driver do the probe, using 0-byte
reads. In the future, i2c-core will be extended to let callers of
i2c_new_probed_device() provide a custom probing function.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Tested-by: "Timothy D. Lenz" <tlenz@vorgon.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Ang Way Chuang [Thu, 27 May 2010 05:02:09 +0000 (02:02 -0300)]
V4L/DVB: dvb-core: Fix ULE decapsulation bug
commit
5c331fc8c19e181bffab46e9d18e1637cdc47170 upstream.
Fix ULE decapsulation bug when less than 4 bytes of ULE SNDU is packed
into the remaining bytes of a MPEG2-TS frame
ULE (Unidirectional Lightweight Encapsulation RFC 4326) decapsulation
code has a bug that incorrectly treats ULE SNDU packed into the
remaining 2 or 3 bytes of a MPEG2-TS frame as having invalid pointer
field on the subsequent MPEG2-TS frame.
Signed-off-by: Ang Way Chuang <wcang@nav6.org>
Acked-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Giuliano Pochini [Tue, 16 Feb 2010 23:57:44 +0000 (00:57 +0100)]
ALSA: Echoaudio, fix Guru Meditation #
00000005.
48454C50
commit
b721e68bdc5b39c51bf6a1469f8d3663fbe03243 upstream.
This patch fixes a division by zero error in the irq handler.
There is a small window between the hw_params() callback and when
runtime->frame_bits is set by ALSA middle layer. When another substream is
already running, if an interrupt is delivered during that window the irq
handler calls pcm_pointer() which does a division by zero. The patch below
makes the irq handler skip substreams that are initialized but not started
yet. Cc to Clemens Ladisch because he proposed an alternate fix.
For more information, please read the original thread in the linux-kernel
mailing list: http://lkml.org/lkml/2010/2/2/187
Signed-off-by: Giuliano Pochini <pochini@shiny.it>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Andrej Gelenberg [Fri, 14 May 2010 22:15:58 +0000 (15:15 -0700)]
revert "[CPUFREQ] remove rwsem lock from CPUFREQ_GOV_STOP call (second call site)"
commit
accd846698439ba18250e8fd5681af280446b853 upstream.
395913d0b1db37092ea3d9d69b832183b1dd84c5 ("[CPUFREQ] remove rwsem lock
from CPUFREQ_GOV_STOP call (second call site)") is not needed, because
there is no rwsem lock in cpufreq_ondemand and cpufreq_conservative
anymore. Lock should not be released until the work done.
Addresses https://bugzilla.kernel.org/show_bug.cgi?id=1594
Signed-off-by: Andrej Gelenberg <andrej.gelenberg@udo.edu>
Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: Dave Jones <davej@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
David Woodhouse [Sun, 2 May 2010 08:21:21 +0000 (11:21 +0300)]
firmware_class: fix memory leak - free allocated pages
commit
dd336c554d8926c3348a2d5f2a5ef5597f6d1a06 upstream.
fix memory leak introduced by the patch
6e03a201bbe:
firmware: speed up request_firmware()
1. vfree won't release pages there were allocated explicitly and mapped
using vmap. The memory has to be vunmap-ed and the pages needs
to be freed explicitly
2. page array is moved into the 'struct
firmware' so that we can free it from release_firmware()
and not only in fw_dev_release()
The fix doesn't break the firmware load speed.
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: Ming Lei <tom.leiming@gmail.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Singed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Baruch Siach [Tue, 18 May 2010 00:45:48 +0000 (17:45 -0700)]
dm9000: fix "BUG: spinlock recursion"
commit
380fefb2ddabd4cd5f14dbe090481f0544e65078 upstream.
dm9000_set_rx_csum and dm9000_hash_table are called from atomic context (in
dm9000_init_dm9000), and from non-atomic context (via ethtool_ops and
net_device_ops respectively). This causes a spinlock recursion BUG. Fix this by
renaming these functions to *_unlocked for the atomic context, and make the
original functions locking wrappers for use in the non-atomic context.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Daniel Mack [Tue, 6 Apr 2010 08:52:44 +0000 (10:52 +0200)]
libertas/sdio: 8686: set ECSI bit for 1-bit transfers
commit
8a64c0f6b7ec7f758c4ef445e49f479e27fa2236 upstream.
When operating in 1-bit mode, SDAT1 is used as dedicated interrupt line.
However, the 8686 will only drive this line when the ECSI bit is set in
the CCCR_IF register.
Thanks to Alagu Sankar for pointing me in the right direction.
Signed-off-by: Daniel Mack <daniel@caiaq.de>
Cc: Alagu Sankar <alagusankar@embwise.com>
Cc: Volker Ernst <volker.ernst@txtr.com>
Cc: Dan Williams <dcbw@redhat.com>
Cc: John W. Linville <linville@tuxdriver.com>
Cc: Holger Schurig <hs4233@mail.mn-solutions.de>
Cc: Bing Zhao <bzhao@marvell.com>
Cc: libertas-dev@lists.infradead.org
Cc: linux-wireless@vger.kernel.org
Cc: linux-mmc@vger.kernel.org
Acked-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Matthew Garrett [Tue, 11 May 2010 17:49:25 +0000 (13:49 -0400)]
ACPI: Unconditionally set SCI_EN on resume
commit
b6dacf63e9fb2e7a1369843d6cef332f76fca6a3 upstream.
The ACPI spec tells us that the firmware will reenable SCI_EN on resume.
Reality disagrees in some cases. The ACPI spec tells us that the only way
to set SCI_EN is via an SMM call.
https://bugzilla.kernel.org/show_bug.cgi?id=13745 shows us that doing so
may break machines. Tracing the ACPI calls made by Windows shows that it
unconditionally sets SCI_EN on resume with a direct register write, and
therefore the overwhelming probability is that everything is fine with
this behaviour.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Tested-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
Cc: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Len Brown [Thu, 22 Jul 2010 20:54:27 +0000 (16:54 -0400)]
ACPI: skip checking BM_STS if the BIOS doesn't ask for it
commit
718be4aaf3613cf7c2d097f925abc3d3553c0605 upstream.
It turns out that there is a bit in the _CST for Intel FFH C3
that tells the OS if we should be checking BM_STS or not.
Linux has been unconditionally checking BM_STS.
If the chip-set is configured to enable BM_STS,
it can retard or completely prevent entry into
deep C-states -- as illustrated by turbostat:
http://userweb.kernel.org/~lenb/acpi/utils/pmtools/turbostat/
ref: Intel Processor Vendor-Specific ACPI Interface Specification
table 4 "_CST FFH GAS Field Encoding"
Bit 1: Set to 1 if OSPM should use Bus Master avoidance for this C-state
https://bugzilla.kernel.org/show_bug.cgi?id=15886
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Ondrej Zary [Mon, 7 Jun 2010 22:32:49 +0000 (00:32 +0200)]
PM / x86: Save/restore MISC_ENABLE register
commit
85a0e7539781dad4bfcffd98e72fa9f130f4e40d upstream.
Save/restore MISC_ENABLE register on suspend/resume.
This fixes OOPS (invalid opcode) on resume from STR on Asus P4P800-VM,
which wakes up with MWAIT disabled.
Fixes https://bugzilla.kernel.org/show_bug.cgi?id=15385
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
Tested-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Steven Whitehouse [Fri, 2 Oct 2009 10:50:54 +0000 (11:50 +0100)]
GFS2: Fix up system xattrs
commit
2646a1f61a3b5525914757f10fa12b5b94713648 upstream.
This code has been shamelessly stolen from XFS at the suggestion
of Christoph Hellwig. I've not added support for cached ACLs so
far... watch for that in a later patch, although this is designed
in such a way that they should be easy to add.
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
Cc: Christoph Hellwig <hch@infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Michal Hocko [Wed, 30 Jun 2010 07:51:19 +0000 (09:51 +0200)]
futex: futex_find_get_task remove credentails check
commit
7a0ea09ad5352efce8fe79ed853150449903b9f5 upstream.
futex_find_get_task is currently used (through lookup_pi_state) from two
contexts, futex_requeue and futex_lock_pi_atomic. None of the paths
looks it needs the credentials check, though. Different (e)uids
shouldn't matter at all because the only thing that is important for
shared futex is the accessibility of the shared memory.
The credentail check results in glibc assert failure or process hang (if
glibc is compiled without assert support) for shared robust pthread
mutex with priority inheritance if a process tries to lock already held
lock owned by a process with a different euid:
pthread_mutex_lock.c:312: __pthread_mutex_lock_full: Assertion `(-(e)) != 3 || !robust' failed.
The problem is that futex_lock_pi_atomic which is called when we try to
lock already held lock checks the current holder (tid is stored in the
futex value) to get the PI state. It uses lookup_pi_state which in turn
gets task struct from futex_find_get_task. ESRCH is returned either
when the task is not found or if credentials check fails.
futex_lock_pi_atomic simply returns if it gets ESRCH. glibc code,
however, doesn't expect that robust lock returns with ESRCH because it
should get either success or owner died.
Signed-off-by: Michal Hocko <mhocko@suse.cz>
Acked-by: Darren Hart <dvhltc@us.ibm.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Nick Piggin <npiggin@suse.de>
Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Cc: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Marcelo Tosatti [Fri, 28 May 2010 12:44:59 +0000 (09:44 -0300)]
KVM: MMU: invalidate and flush on spte small->large page size change
Always invalidate spte and flush TLBs when changing page size, to make
sure different sized translations for the same address are never cached
in a CPU's TLB.
Currently the only case where this occurs is when a non-leaf spte pointer is
overwritten by a leaf, large spte entry. This can happen after dirty
logging is disabled on a memslot, for example.
Noticed by Andrea.
KVM-Stable-Tag
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Avi Kivity <avi@redhat.com>
(cherry picked from commit
3be2264be3c00865116f997dc53ebcc90fe7fc4b)
Joerg Roedel [Mon, 17 May 2010 12:43:35 +0000 (14:43 +0200)]
KVM: SVM: Implement workaround for Erratum 383
This patch implements a workaround for AMD erratum 383 into
KVM. Without this erratum fix it is possible for a guest to
kill the host machine. This patch implements the suggested
workaround for hypervisors which will be published by the
next revision guide update.
[jan: fix overflow warning on i386]
[xiao: fix unused variable warning]
Cc: stable@kernel.org
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Xiao Guangrong <xiaoguangrong@cn.fujitsu.com>
Signed-off-by: Avi Kivity <avi@redhat.com>
(cherry picked from commit
67ec66077799f2fef84b21a643912b179c422281)
Joerg Roedel [Mon, 17 May 2010 12:43:34 +0000 (14:43 +0200)]
KVM: SVM: Handle MCEs early in the vmexit process
This patch moves handling of the MC vmexits to an earlier
point in the vmexit. The handle_exit function is too late
because the vcpu might alreadry have changed its physical
cpu.
Cc: stable@kernel.org
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Signed-off-by: Avi Kivity <avi@redhat.com>
(cherry picked from commit
fe5913e4e1700cbfc337f4b1da9ddb26f6a55586)
Avi Kivity [Thu, 27 May 2010 11:35:58 +0000 (14:35 +0300)]
KVM: MMU: Remove user access when allowing kernel access to gpte.w=0 page
If cr0.wp=0, we have to allow the guest kernel access to a page with pte.w=0.
We do that by setting spte.w=1, since the host cr0.wp must remain set so the
host can write protect pages. Once we allow write access, we must remove
user access otherwise we mistakenly allow the user to write the page.
Reviewed-by: Xiao Guangrong <xiaoguangrong@cn.fujitsu.com>
Signed-off-by: Avi Kivity <avi@redhat.com>
(cherry picked from commit
69325a122580d3a7b26589e8efdd6663001c3297)
Frank Mayhar [Mon, 31 May 2010 02:50:06 +0000 (22:50 -0400)]
ext4: Make fsync sync new parent directories in no-journal mode
commit
14ece1028b3ed53ffec1b1213ffc6acaf79ad77c upstream (as of v2.6.34-git13)
Add a new ext4 state to tell us when a file has been newly created; use
that state in ext4_sync_file in no-journal mode to tell us when we need
to sync the parent directory as well as the inode and data itself. This
fixes a problem in which a panic or power failure may lose the entire
file even when using fsync, since the parent directory entry is lost.
Addresses-Google-Bug: #
2480057
Signed-off-by: Frank Mayhar <fmayhar@google.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Ben Hutchings [Mon, 31 May 2010 02:50:05 +0000 (22:50 -0400)]
ext4: Fix compat EXT4_IOC_ADD_GROUP
commit
4d92dc0f00a775dc2e1267b0e00befb783902fe7 upstream (as of v2.6.34-git13)
struct ext4_new_group_input needs to be converted because u64 has
only 32-bit alignment on some 32-bit architectures, notably i386.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Ben Hutchings [Mon, 31 May 2010 02:50:04 +0000 (22:50 -0400)]
ext4: Conditionally define compat ioctl numbers
commit
899ad0cea6ad7ff4ba24b16318edbc3cbbe03fad upstream (as of v2.6.34-git13)
It is unnecessary, and in general impossible, to define the compat
ioctl numbers except when building the filesystem with CONFIG_COMPAT
defined.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dmitry Monakhov [Mon, 31 May 2010 02:50:03 +0000 (22:50 -0400)]
ext4: restart ext4_ext_remove_space() after transaction restart
commit
0617b83fa239db9743a18ce6cc0e556f4d0fd567 upstream (as of v2.6.34-git13)
If i_data_sem was internally dropped due to transaction restart, it is
necessary to restart path look-up because extents tree was possibly
modified by ext4_get_block().
https://bugzilla.kernel.org/show_bug.cgi?id=15827
Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Acked-by: Jan Kara <jack@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Theodore Ts'o [Mon, 31 May 2010 02:50:02 +0000 (22:50 -0400)]
ext4: Clear the EXT4_EOFBLOCKS_FL flag only when warranted
commit
786ec7915e530936b9eb2e3d12274145cab7aa7d upstream (as of v2.6.34-git13)
Dimitry Monakhov discovered an edge case where it was possible for the
EXT4_EOFBLOCKS_FL flag could get cleared unnecessarily. This is true;
I have a test case that can be exercised via downloading and
decompressing the file:
wget ftp://ftp.kernel.org/pub/linux/kernel/people/tytso/ext4-testcases/eofblocks-fl-test-case.img.bz2
bunzip2 eofblocks-fl-test-case.img
dd if=/dev/zero of=eofblocks-fl-test-case.img bs=1k seek=17925 bs=1k count=1 conv=notrunc
However, triggering it in real life is highly unlikely since it
requires an extremely fragmented sparse file with a hole in exactly
the right place in the extent tree. (It actually took quite a bit of
work to generate this test case.) Still, it's nice to get even
extreme corner cases to be correct, so this patch makes sure that we
don't clear the EXT4_EOFBLOCKS_FL incorrectly even in this corner
case.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Theodore Ts'o [Mon, 31 May 2010 02:50:01 +0000 (22:50 -0400)]
ext4: Avoid crashing on NULL ptr dereference on a filesystem error
commit
f70f362b4a6fe47c239dbfb3efc0cc2c10e4f09c upstream (as of v2.6.34-git13)
If the EOFBLOCK_FL flag is set when it should not be and the inode is
zero length, then eh_entries is zero, and ex is NULL, so dereferencing
ex to print ex->ee_block causes a kernel OOPS in
ext4_ext_map_blocks().
On top of that, the error message which is printed isn't very helpful.
So we fix this by printing something more explanatory which doesn't
involve trying to print ex->ee_block.
Addresses-Google-Bug: #
2655740
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dmitry Monakhov [Mon, 31 May 2010 02:50:00 +0000 (22:50 -0400)]
ext4: Use bitops to read/modify i_flags in struct ext4_inode_info
commit
12e9b892002d9af057655d35b44db8ee9243b0dc upstream (as of v2.6.34-git13)
At several places we modify EXT4_I(inode)->i_flags without holding
i_mutex (ext4_do_update_inode, ...). These modifications are racy and
we can lose updates to i_flags. So convert handling of i_flags to use
bitops which are atomic.
https://bugzilla.kernel.org/show_bug.cgi?id=15792
Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jan Kara [Mon, 31 May 2010 02:49:59 +0000 (22:49 -0400)]
ext4: Show journal_checksum option
commit
39a4bade8c1826b658316d66ee81c09b0a4d7d42 upstream (as of v2.6.34-git13)
We failed to show journal_checksum option in /proc/mounts. Fix it.
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Curt Wohlgemuth [Mon, 31 May 2010 02:49:58 +0000 (22:49 -0400)]
ext4: check for a good block group before loading buddy pages
commit
8a57d9d61a6e361c7bb159dda797672c1df1a691 upstream (as of v2.6.34-git13)
This adds a new field in ext4_group_info to cache the largest available
block range in a block group; and don't load the buddy pages until *after*
we've done a sanity check on the block group.
With large allocation requests (e.g., fallocate(), 8MiB) and relatively full
partitions, it's easy to have no block groups with a block extent large
enough to satisfy the input request length. This currently causes the loop
during cr == 0 in ext4_mb_regular_allocator() to load the buddy bitmap pages
for EVERY block group. That can be a lot of pages. The patch below allows
us to call ext4_mb_good_group() BEFORE we load the buddy pages (although we
have check again after we lock the block group).
Addresses-Google-Bug: #
2578108
Addresses-Google-Bug: #
2704453
Signed-off-by: Curt Wohlgemuth <curtw@google.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Nikanth Karthikesan [Mon, 31 May 2010 02:49:57 +0000 (22:49 -0400)]
ext4: Prevent creation of files larger than RLIMIT_FSIZE using fallocate
commit
6d19c42b7cf81c39632b6d4dbc514e8449bcd346 upstream (as of v2.6.34-git13)
Currently using posix_fallocate one can bypass an RLIMIT_FSIZE limit
and create a file larger than the limit. Add a check for that.
Signed-off-by: Nikanth Karthikesan <knikanth@suse.de>
Signed-off-by: Amit Arora <aarora@in.ibm.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Curt Wohlgemuth [Mon, 31 May 2010 02:49:56 +0000 (22:49 -0400)]
ext4: Remove extraneous newlines in ext4_msg() calls
commit
fbe845ddf368f77f86aa7500f8fd2690f54c66a8 upstream (as of v2.6.34-git13)
Addresses-Google-Bug: #
2562325
Signed-off-by: Curt Wohlgemuth <curtw@google.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dmitry Monakhov [Mon, 31 May 2010 02:49:55 +0000 (22:49 -0400)]
ext4: init statistics after journal recovery
commit
84061e07c5fbbbf9dc8aef8fb750fc3a2dfc31f3 upstream (as of v2.6.34-git13)
Currently block/inode/dir counters initialized before journal was
recovered. In fact after journal recovery this info will probably
change. And freeblocks it critical for correct delalloc mode
accounting.
https://bugzilla.kernel.org/show_bug.cgi?id=15768
Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
Acked-by: Jan Kara <jack@suse.cz>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dmitry Monakhov [Mon, 31 May 2010 02:49:54 +0000 (22:49 -0400)]
ext4: clean up inode bitmaps manipulation in ext4_free_inode
commit
d17413c08cd2b1dd2bf2cfdbb0f7b736b2b2b15c upstrea (as of v2..34-git13)
- Reorganize locking scheme to batch two atomic operation in to one.
This also allow us to state what healthy group must obey following rule
ext4_free_inodes_count(sb, gdp) == ext4_count_free(inode_bitmap, NUM);
- Fix possible undefined pointer dereference.
- Even if group descriptor stats aren't accessible we have to update
inode bitmaps.
- Move non-group members update out of group_lock.
Note: this commit has been observed to fix fs corruption problems
under heavy fs load
Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dmitry Monakhov [Mon, 31 May 2010 02:49:53 +0000 (22:49 -0400)]
ext4: Do not zero out uninitialized extents beyond i_size
commit
21ca087a3891efab4d45488db8febee474d26c68 upstream (as of v2.6.34-git13)
The extents code will sometimes zero out blocks and mark them as
initialized instead of splitting an extent into several smaller ones.
This optimization however, causes problems if the extent is beyond
i_size because fsck will complain if there are uninitialized blocks
after i_size as this can not be distinguished from an inode that has
an incorrect i_size field.
https://bugzilla.kernel.org/show_bug.cgi?id=15742
Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Eric Sandeen [Mon, 31 May 2010 02:49:52 +0000 (22:49 -0400)]
ext4: don't scan/accumulate more pages than mballoc will allocate
commit
c445e3e0a5c2804524dec6e55f66d63f6bc5bc3e upstream (as of v2.6.34-git13)
There was a bug reported on RHEL5 that a 10G dd on a 12G box
had a very, very slow sync after that.
At issue was the loop in write_cache_pages scanning all the way
to the end of the 10G file, even though the subsequent call
to mpage_da_submit_io would only actually write a smallish amt; then
we went back to the write_cache_pages loop ... wasting tons of time
in calling __mpage_da_writepage for thousands of pages we would
just revisit (many times) later.
Upstream it's not such a big issue for sys_sync because we get
to the loop with a much smaller nr_to_write, which limits the loop.
However, talking with Aneesh he realized that fsync upstream still
gets here with a very large nr_to_write and we face the same problem.
This patch makes mpage_add_bh_to_extent stop the loop after we've
accumulated 2048 pages, by setting mpd->io_done = 1; which ultimately
causes the write_cache_pages loop to break.
Repeating the test with a dirty_ratio of 80 (to leave something for
fsync to do), I don't see huge IO performance gains, but the reduction
in cpu usage is striking: 80% usage with stock, and 2% with the
below patch. Instrumenting the loop in write_cache_pages clearly
shows that we are wasting time here.
Eventually we need to change mpage_da_map_pages() also submit its I/O
to the block layer, subsuming mpage_da_submit_io(), and then change it
call ext4_get_blocks() multiple times.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Eric Sandeen [Mon, 31 May 2010 02:49:51 +0000 (22:49 -0400)]
ext4: stop issuing discards if not supported by device
commit
a30eec2a8650a77f754e84b2e15f062fe652baa7 upstream (as of v2.6.34-git13)
Turn off issuance of discard requests if the device does
not support it - similar to the action we take for barriers.
This will save a little computation time if a non-discardable
device is mounted with -o discard, and also makes it obvious
that it's not doing what was asked at mount time ...
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Eric Sandeen [Mon, 31 May 2010 02:49:50 +0000 (22:49 -0400)]
ext4: don't return to userspace after freezing the fs with a mutex held
commit
6b0310fbf087ad6e9e3b8392adca97cd77184084 upstream (as of v2.6.34-git13)
ext4_freeze() used jbd2_journal_lock_updates() which takes
the j_barrier mutex, and then returns to userspace. The
kernel does not like this:
================================================
[ BUG: lock held when returning to user space! ]
------------------------------------------------
lvcreate/1075 is leaving the kernel with locks still held!
1 lock held by lvcreate/1075:
#0: (&journal->j_barrier){+.+...}, at: [<
ffffffff811c6214>]
jbd2_journal_lock_updates+0xe1/0xf0
Use vfs_check_frozen() added to ext4_journal_start_sb() and
ext4_force_commit() instead.
Addresses-Red-Hat-Bugzilla: #568503
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Eric Sandeen [Mon, 31 May 2010 02:49:49 +0000 (22:49 -0400)]
ext4: check s_log_groups_per_flex in online resize code
commit
42007efd569f1cf3bfb9a61da60ef6c2179508ca upstream (as of v2.6.34-git13)
If groups_per_flex < 2, sbi->s_flex_groups[] doesn't get filled out,
and every other access to this first tests s_log_groups_per_flex;
same thing needs to happen in resize or we'll wander off into
a null pointer when doing an online resize of the file system.
Thanks to Christoph Biedl, who came up with the trivial testcase:
# truncate --size 128M fsfile
# mkfs.ext3 -F fsfile
# tune2fs -O extents,uninit_bg,dir_index,flex_bg,huge_file,dir_nlink,extra_isize fsfile
# e2fsck -yDf -C0 fsfile
# truncate --size 132M fsfile
# losetup /dev/loop0 fsfile
# mount /dev/loop0 mnt
# resize2fs -p /dev/loop0
https://bugzilla.kernel.org/show_bug.cgi?id=13549
Reported-by: Alessandro Polverini <alex@nibbles.it>
Test-case-by: Christoph Biedl <bugzilla.kernel.bpeb@manchmal.in-ulm.de>
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dmitry Monakhov [Mon, 31 May 2010 02:49:48 +0000 (22:49 -0400)]
ext4: fix quota accounting in case of fallocate
commit
35121c9860316d7799cea0fbc359a9186e7c2747 upstream (as of v2.6.34-git13)
allocated_meta_data is already included in 'used' variable.
Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Christian Borntraeger [Mon, 31 May 2010 02:49:47 +0000 (22:49 -0400)]
ext4: allow defrag (EXT4_IOC_MOVE_EXT) in 32bit compat mode
commit
b684b2ee9409f2890a8b3aea98525bbe5f84e276 upstream (as of v2.6.34-git13)
I have an x86_64 kernel with i386 userspace. e4defrag fails on the
EXT4_IOC_MOVE_EXT ioctl because it is not wired up for the compat
case. It seems that struct move_extent is compat save, only types
with fixed widths are used:
{
__u32 reserved; /* should be zero */
__u32 donor_fd; /* donor file descriptor */
__u64 orig_start; /* logical start offset in block for orig */
__u64 donor_start; /* logical start offset in block for donor */
__u64 len; /* block length to be moved */
__u64 moved_len; /* moved block length */
};
Lets just wire up EXT4_IOC_MOVE_EXT for the compat case.
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
CC: Akira Fujita <a-fujita@rs.jp.nec.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jing Zhang [Mon, 31 May 2010 02:49:46 +0000 (22:49 -0400)]
ext4: rename ext4_mb_release_desc() to ext4_mb_unload_buddy()
commit
e39e07fdfd98be8650385f12a7b81d6adc547510 upstream (as of v2.6.34-git13)
This function cleans up after ext4_mb_load_buddy(), so the renaming
makes the code clearer.
Signed-off-by: Jing Zhang <zj.barak@gmail.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jing Zhang [Mon, 31 May 2010 02:49:45 +0000 (22:49 -0400)]
ext4: Remove unnecessary call to ext4_get_group_desc() in mballoc
commit
62e823a2cba18509ee826d775270e8ef9071b5bc upstream (as of v2.6.34-git13)
Signed-off-by: Jing Zhang <zj.barak@gmail.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jing Zhang [Mon, 31 May 2010 02:49:44 +0000 (22:49 -0400)]
ext4: fix memory leaks in error path handling of ext4_ext_zeroout()
commit
b720303df7352d4a7a1f61e467e0a124913c0d41 upstream (as of v2.6.34-git13)
When EIO occurs after bio is submitted, there is no memory free
operation for bio, which results in memory leakage. And there is also
no check against bio_alloc() for bio.
Acked-by: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
Signed-off-by: Jing Zhang <zj.barak@gmail.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dmitry Monakhov [Mon, 31 May 2010 02:49:43 +0000 (22:49 -0400)]
ext4: check missed return value in ext4_sync_file()
commit
0671e704658b9f26f85e78d51176daa861f955c7 upstream (as of v2.6.34-git13)
Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Theodore Ts'o [Mon, 31 May 2010 02:49:42 +0000 (22:49 -0400)]
ext4: Issue the discard operation *before* releasing the blocks to be reused
commit
b90f687018e6d6c77d981b09203780f7001407e5 upstream (as of v2.6.34-rc6)
Otherwise, we can end up having data corruption because the blocks
could get reused and then discarded!
https://bugzilla.kernel.org/show_bug.cgi?id=15579
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Curt Wohlgemuth [Mon, 31 May 2010 02:49:41 +0000 (22:49 -0400)]
ext4: Fix buffer head leaks after calls to ext4_get_inode_loc()
commit
fd2dd9fbaf9e498ec63eef298921e36556f7214c upstream (as of v2.6.34-rc6)
Calls to ext4_get_inode_loc() returns with a reference to a buffer
head in iloc->bh. The callers of this function in ext4_write_inode()
when in no journal mode and in ext4_xattr_fiemap() don't release the
buffer head after using it.
Addresses-Google-Bug: #
2548165
Signed-off-by: Curt Wohlgemuth <curtw@google.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Curt Wohlgemuth [Mon, 31 May 2010 02:49:40 +0000 (22:49 -0400)]
ext4: Fix possible lost inode write in no journal mode
commit
8b472d739b2ddd8ab7fb278874f696cd95b25a5e upstream (as of v2.6.34-rc6)
In the no-journal case, ext4_write_inode() will fetch the bh and call
sync_dirty_buffer() on it. However, if the bh has already been
written and the bh reclaimed for some other purpose, AND if the inode
is the only one in the inode table block in use, then
ext4_get_inode_loc() will not read the inode table block from disk,
but as an optimization, fill the block with zero's assuming that its
caller will copy in the on-disk version of the inode. This is not
done by ext4_write_inode(), so the contents of the inode can simply
get lost. The fix is to use __ext4_get_inode_loc() with in_mem set to
0, instead of ext4_get_inode_loc(). Long term the API needs to be
fixed so it's obvious why latter is not safe.
Addresses-Google-Bug: #
2526446
Signed-off-by: Curt Wohlgemuth <curtw@google.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Eric Sandeen [Mon, 31 May 2010 02:49:39 +0000 (22:49 -0400)]
ext4: Fixed inode allocator to correctly track a flex_bg's used_dirs
commit
c4caae25187ff3f5e837c6f04eb1acc2723c72d3 upstream (as of v2.6.34-rc3)
When used_dirs was introduced for the flex_groups struct, it looks
like the accounting was not put into place properly, in some places
manipulating free_inodes rather than used_dirs.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jan Kara [Mon, 31 May 2010 02:49:38 +0000 (22:49 -0400)]
ext4: Fix estimate of # of blocks needed to write indirect-mapped files
commit
d330a5befb88875a9b3d2db62f9b74dadf660b13 upstream (as of v2.6.34-rc3)
http://bugzilla.kernel.org/show_bug.cgi?id=15420
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Akira Fujita [Mon, 31 May 2010 02:49:37 +0000 (22:49 -0400)]
ext4: Code cleanup for EXT4_IOC_MOVE_EXT ioctl
commit
c437b2733520599a2c6e0dbcdeae611319f84707 upstream (as of v2.6.33-git11)
a) Fix sparse warning in ext4_ioctl()
b) Remove unneeded variable in mext_leaf_block()
c) Fix spelling typo in mext_check_arguments()
Signed-off-by: Akira Fujita <a-fujita@rs.jp.nec.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Akira Fujita [Mon, 31 May 2010 02:49:36 +0000 (22:49 -0400)]
ext4: Fix the NULL reference in double_down_write_data_sem()
commit
7247c0caa23d94a1cb6b307edba9dc45fb0798d4 upstream (as of v2.6.33-git11)
If EXT4_IOC_MOVE_EXT ioctl is called with NULL donor_fd, fget() in
ext4_ioctl() gets inappropriate file structure for donor; so we need
to do this check earlier, before calling double_down_write_data_sem().
Signed-off-by: Akira Fujita <a-fujita@rs.jp.nec.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Akira Fujita [Mon, 31 May 2010 02:49:35 +0000 (22:49 -0400)]
ext4: Fix insertion point of extent in mext_insert_across_blocks()
commit
5fd5249aa36fad98c9fd5edced352939e54f9324 upstream (as of v2.6.33-git11)
If the leaf node has 2 extent space or fewer and EXT4_IOC_MOVE_EXT
ioctl is called with the file offset where after the 2nd extent
covers, mext_insert_across_blocks() always tries to insert extent into
the first extent. As a result, the file gets corrupted because of
wrong extent order. The patch fixes this problem.
Signed-off-by: Akira Fujita <a-fujita@rs.jp.nec.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Toshiyuki Okajima [Mon, 31 May 2010 02:49:34 +0000 (22:49 -0400)]
ext4: make "offset" consistent in ext4_check_dir_entry()
commit
b8b8afe236e97b6359d46d3a3f8c46455e192271 upstream (as of v2.6.33-git11)
The callers of ext4_check_dir_entry() usually pass in the "file
offset" (ext4_readdir, htree_dirblock_to_tree, search_dirblock,
ext4_dx_find_entry, empty_dir), but a few callers (add_dirent_to_buf,
ext4_delete_entry) only pass in the buffer offset.
To accomodate those last two (which would be hard to fix otherwise),
this patch changes ext4_check_dir_entry() to print the physical block
number and the relative offset as well as the passed-in offset.
Signed-off-by: Toshiyuki Okajima <toshi.okajima@jp.fujitsu.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dmitry Monakhov [Mon, 31 May 2010 02:49:33 +0000 (22:49 -0400)]
ext4: Handle non empty on-disk orphan link
commit
6e3617e579e070d3655a93ee9ed7149113e795e0 upstream (as of v2.6.33-git11)
In case of truncate errors we explicitly remove inode from in-core
orphan list via orphan_del(NULL, inode) without modifying the on-disk list.
But later on, the same inode may be inserted in the orphan list again
which will result the on-disk linked list getting corrupted. If inode
i_dtime contains valid value, then skip on-disk list modification.
Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dmitry Monakhov [Mon, 31 May 2010 02:49:32 +0000 (22:49 -0400)]
ext4: explicitly remove inode from orphan list after failed direct io
commit
da1dafca84413145f5ac59998b4cdd06fb89f721 upstream (as of v2.6.33-git11)
Otherwise non-empty orphan list will be triggered on umount.
Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dmitry Monakhov [Mon, 31 May 2010 02:49:31 +0000 (22:49 -0400)]
ext4: fix error handling in migrate
commit
f39490bcd1691d65dc33689222a12e1fc13dd824 upstream (as of v2.6.33-git11)
Set i_nlink to zero for temporary inode from very beginning.
otherwise we may fail to start new journal handle and this
inode will be unreferenced but with i_nlink == 1
Since we hold inode reference it can not be pruned.
Also add missed journal_start retval check.
Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Tao Ma [Mon, 31 May 2010 02:49:30 +0000 (22:49 -0400)]
ext4: Fix fencepost error in chosing choosing group vs file preallocation.
commit
cc483f102c3f703e853c96f95a654f0106fb2603 upstream (as of v2.6.33-git11)
The ext4 multiblock allocator decides whether to use group or file
preallocation based on the file size. When the file size reaches
s_mb_stream_request (default is 16 blocks), it changes to use a
file-specific preallocation. This is cool, but it has a tiny problem.
See a simple script:
mkfs.ext4 -b 1024 /dev/sda8
1000000
mount -t ext4 -o nodelalloc /dev/sda8 /mnt/ext4
for((i=0;i<5;i++))
do
cat /mnt/4096>>/mnt/ext4/a #4096 is a file with 4096 characters.
cat /mnt/4096>>/mnt/ext4/b
done
debuge4fs -R 'stat a' /dev/sda8|grep BLOCKS -A 1
And you get
BLOCKS:
(0-14):8705-8719, (15):2356, (16-19):8465-8468
So there are 3 extents, a bit strange for the lonely 15th logical
block. As we write to the 16 blocks, we choose file preallocation in
ext4_mb_group_or_file, but in ext4_mb_normalize_request, we meet with
the 16*1024 range, so no preallocation will be carried. file b then
reserves the space after '2356', so when when write 16, we start from
another part.
This patch just change the check in ext4_mb_group_or_file, so
that for the lonely 15 we will still use group preallocation.
After the patch, we will get:
debuge4fs -R 'stat a' /dev/sda8|grep BLOCKS -A 1
BLOCKS:
(0-15):8705-8720, (16-19):8465-8468
Looks more sane. Thanks.
Signed-off-by: Tao Ma <tao.ma@oracle.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jiaying Zhang [Mon, 31 May 2010 02:49:29 +0000 (22:49 -0400)]
ext4: Add flag to files with blocks intentionally past EOF
commit
c8d46e41bc744c8fa0092112af3942fcd46c8b18 upstream (as of v2.6.33-git11)
fallocate() may potentially instantiate blocks past EOF, depending
on the flags used when it is called.
e2fsck currently has a test for blocks past i_size, and it
sometimes trips up - noticeably on xfstests 013 which runs fsstress.
This patch from Jiayang does fix it up - it (along with
e2fsprogs updates and other patches recently from Aneesh) has
survived many fsstress runs in a row.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Jiaying Zhang <jiayingz@google.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Curt Wohlgemuth [Mon, 31 May 2010 02:49:28 +0000 (22:49 -0400)]
ext4: Fix BUG_ON at fs/buffer.c:652 in no journal mode
commit
73b50c1c92666d326b5fa2c945d46509f2f6d91f upstream (as of v2.6.33-git11)
Calls to ext4_handle_dirty_metadata should only pass in an inode
pointer for inode-specific metadata, and not for shared metadata
blocks such as inode table blocks, block group descriptors, the
superblock, etc.
The BUG_ON can get tripped when updating a special device (such as a
block device) that is opened (so that i_mapping is set in
fs/block_dev.c) and the file system is mounted in no journal mode.
Addresses-Google-Bug: #
2404870
Signed-off-by: Curt Wohlgemuth <curtw@google.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Theodore Ts'o [Mon, 31 May 2010 02:49:27 +0000 (22:49 -0400)]
ext4: Use bitops to read/modify EXT4_I(inode)->i_state
commit
19f5fb7ad679bb361222c7916086435020c37cce upstream (as of v2.6.33-git11)
At several places we modify EXT4_I(inode)->i_state without holding
i_mutex (ext4_release_file, ext4_bmap, ext4_journalled_writepage,
ext4_do_update_inode, ...). These modifications are racy and we can
lose updates to i_state. So convert handling of i_state to use bitops
which are atomic.
Cc: Jan Kara <jack@suse.cz>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Aneesh Kumar K.V [Mon, 31 May 2010 02:49:26 +0000 (22:49 -0400)]
ext4: Drop EXT4_GET_BLOCKS_UPDATE_RESERVE_SPACE flag
commit
1296cc85c26e94eb865d03f82140f27d598de467 upstream (as of v2.6.33-rc6)
We should update reserve space if it is delalloc buffer
and that is indicated by EXT4_GET_BLOCKS_DELALLOC_RESERVE flag.
So use EXT4_GET_BLOCKS_DELALLOC_RESERVE in place of
EXT4_GET_BLOCKS_UPDATE_RESERVE_SPACE
[ Stable note: This fixes a corruption cuased by the following
reproduction case:
rm -f $TEST_FN
touch $TEST_FN
fallocate -n -o 656712 -l 858907 $TEST_FN
dd if=/dev/zero of=$TEST_FN conv=notrunc bs=1 seek=
1011020 count=36983
sync
dd if=/dev/zero of=$TEST_FN conv=notrunc bs=1 seek=332121 count=24005
dd if=/dev/zero of=$TEST_FN conv=notrunc bs=1 seek=
1040179 count=93319
If the filesystem is then unmounted and e2fsck run forced, the
i_blocks field for the file $TEST_FN will be found to be incorrect. ]
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Aneesh Kumar K.V [Mon, 31 May 2010 02:49:25 +0000 (22:49 -0400)]
ext4: Fix quota accounting error with fallocate
commit
5f634d064c709ea02c3cdaa850a08323a4a4bf28 upstream (as of v2.6.33-rc6)
When we fallocate a region of the file which we had recently written,
and which is still in the page cache marked as delayed allocated blocks
we need to make sure we don't do the quota update on writepage path.
This is because the needed quota updated would have already be done
by fallocate.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Aneesh Kumar K.V [Mon, 31 May 2010 02:49:24 +0000 (22:49 -0400)]
ext4: Handle -EDQUOT error on write
commit
1db913823c0f8360fccbd24ca67eb073966a5ffd upstream (as of v2.6.33-rc6)
We need to release the journal before we do a write_inode. Otherwise
we could deadlock.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Theodore Ts'o [Mon, 31 May 2010 02:49:23 +0000 (22:49 -0400)]
ext4: Calculate metadata requirements more accurately
commit
9d0be50230b333005635967f7ecd4897dbfd181b upstream (as of v2.6.33-rc3)
In the past, ext4_calc_metadata_amount(), and its sub-functions
ext4_ext_calc_metadata_amount() and ext4_indirect_calc_metadata_amount()
badly over-estimated the number of metadata blocks that might be
required for delayed allocation blocks. This didn't matter as much
when functions which managed the reserved metadata blocks were more
aggressive about dropping reserved metadata blocks as delayed
allocation blocks were written, but unfortunately they were too
aggressive. This was fixed in commit
0637c6f, but as a result the
over-estimation by ext4_calc_metadata_amount() would lead to reserving
2-3 times the number of pending delayed allocation blocks as
potentially required metadata blocks. So if there are 1 megabytes of
blocks which have been not yet been allocation, up to 3 megabytes of
space would get reserved out of the user's quota and from the file
system free space pool until all of the inode's data blocks have been
allocated.
This commit addresses this problem by much more accurately estimating
the number of metadata blocks that will be required. It will still
somewhat over-estimate the number of blocks needed, since it must make
a worst case estimate not knowing which physical blocks will be
needed, but it is much more accurate than before.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Theodore Ts'o [Mon, 31 May 2010 02:49:22 +0000 (22:49 -0400)]
ext4: Fix accounting of reserved metadata blocks
commit
ee5f4d9cdf32fd99172d11665c592a288c2b1ff4 upstream (as of v2.6.33-rc3)
Commit
0637c6f had a typo which caused the reserved metadata blocks to
not be released correctly. Fix this.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Theodore Ts'o [Mon, 31 May 2010 02:49:21 +0000 (22:49 -0400)]
ext4: Patch up how we claim metadata blocks for quota purposes
commit
0637c6f4135f592f094207c7c21e7c0fc5557834 upstream (as of v2.6.33-rc3)
As reported in Kernel Bugzilla #14936, commit
d21cd8f triggered a BUG
in the function ext4_da_update_reserve_space() found in
fs/ext4/inode.c. The root cause of this BUG() was caused by the fact
that ext4_calc_metadata_amount() can severely over-estimate how many
metadata blocks will be needed, especially when using direct
block-mapped files.
In addition, it can also badly *under* estimate how much space is
needed, since ext4_calc_metadata_amount() assumes that the blocks are
contiguous, and this is not always true. If the application is
writing blocks to a sparse file, the number of metadata blocks
necessary can be severly underestimated by the functions
ext4_da_reserve_space(), ext4_da_update_reserve_space() and
ext4_da_release_space(). This was the cause of the dq_claim_space
reports found on kerneloops.org.
Unfortunately, doing this right means that we need to massively
over-estimate the amount of free space needed. So in some cases we
may need to force the inode to be written to disk asynchronously in
to avoid spurious quota failures.
http://bugzilla.kernel.org/show_bug.cgi?id=14936
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Aneesh Kumar K.V [Mon, 31 May 2010 02:49:20 +0000 (22:49 -0400)]
ext4: Ensure zeroout blocks have no dirty metadata
commit
515f41c33a9d44a964264c9511ad2c869af1fac3 upstream (as of v2.6.33-rc3)
This fixes a bug (found by Curt Wohlgemuth) in which new blocks
returned from an extent created with ext4_ext_zeroout() can have dirty
metadata still associated with them.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Curt Wohlgemuth <curtw@google.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Richard Kennedy [Mon, 31 May 2010 02:49:19 +0000 (22:49 -0400)]
ext4: return correct wbc.nr_to_write in ext4_da_writepages
commit
2faf2e19dd0e060eeb32442858ef495ac3083277 upstream (as of v2.6.33-rc3)
When ext4_da_writepages increases the nr_to_write in writeback_control
then it must always re-base the return value. Originally there was a
(misguided) attempt prevent wbc.nr_to_write from going negative. In
fact, it's necessary to allow nr_to_write to be negative so that
wb_writeback() can correctly calculate how many pages were actually
written.
Signed-off-by: Richard Kennedy <richard@rsk.demon.co.uk>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Julia Lawall [Mon, 31 May 2010 02:49:18 +0000 (22:49 -0400)]
ext4: Eliminate potential double free on error path
commit
d3533d72e7478a61a3e1936956fc825289a2acf4 upstream (as of v2.6.33-rc3)
b_entry_name and buffer are initially NULL, are initialized within a loop
to the result of calling kmalloc, and are freed at the bottom of this loop.
The loop contains gotos to cleanup, which also frees b_entry_name and
buffer. Some of these gotos are before the reinitializations of
b_entry_name and buffer. To maintain the invariant that b_entry_name and
buffer are NULL at the top of the loop, and thus acceptable arguments to
kfree, these variables are now set to NULL after the kfrees.
This seems to be the simplest solution. A more complicated solution
would be to introduce more labels in the error handling code at the end of
the function.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@r@
identifier E;
expression E1;
iterator I;
statement S;
@@
*kfree(E);
... when != E = E1
when != I(E,...) S
when != &E
*kfree(E);
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Theodore Ts'o [Mon, 31 May 2010 02:49:17 +0000 (22:49 -0400)]
ext4, jbd2: Add barriers for file systems with exernal journals
commit
cc3e1bea5d87635c519da657303690f5538bb4eb upstream (as of v2.6.33-rc3)
This is a bit complicated because we are trying to optimize when we
send barriers to the fs data disk. We could just throw in an extra
barrier to the data disk whenever we send a barrier to the journal
disk, but that's not always strictly necessary.
We only need to send a barrier during a commit when there are data
blocks which are must be written out due to an inode written in
ordered mode, or if fsync() depends on the commit to force data blocks
to disk. Finally, before we drop transactions from the beginning of
the journal during a checkpoint operation, we need to guarantee that
any blocks that were flushed out to the data disk are firmly on the
rust platter before we drop the transaction from the journal.
Thanks to Oleg Drokin for pointing out this flaw in ext3/ext4.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Surbhi Palande [Mon, 31 May 2010 02:49:16 +0000 (22:49 -0400)]
ext4: replace BUG() with return -EIO in ext4_ext_get_blocks
commit
034fb4c95fc0fed4ec4a50778127b92c6f2aec01 upstream (as of v2.6.33-rc3)
This patch fixes the Kernel BZ #14286. When the address of an extent
corresponding to a valid block is corrupted, a -EIO should be reported
instead of a BUG(). This situation should not normally not occur
except in the case of a corrupted filesystem. If however it does,
then the system should not panic directly but depending on the mount
time options appropriate action should be taken. If the mount options
so permit, the I/O should be gracefully aborted by returning a -EIO.
http://bugzilla.kernel.org/show_bug.cgi?id=14286
Signed-off-by: Surbhi Palande <surbhi.palande@canonical.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dmitry Monakhov [Mon, 31 May 2010 02:49:14 +0000 (22:49 -0400)]
ext4: Fix potential quota deadlock
commit
d21cd8f163ac44b15c465aab7306db931c606908 upstream (as of v2.6.33-rc2)
We have to delay vfs_dq_claim_space() until allocation context destruction.
Currently we have following call-trace:
ext4_mb_new_blocks()
/* task is already holding ac->alloc_semp */
->ext4_mb_mark_diskspace_used
->vfs_dq_claim_space() /* acquire dqptr_sem here. Possible deadlock */
->ext4_mb_release_context() /* drop ac->alloc_semp here */
Let's move quota claiming to ext4_da_update_reserve_space()
=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.32-rc7 #18
-------------------------------------------------------
write-truncate-/3465 is trying to acquire lock:
(&s->s_dquot.dqptr_sem){++++..}, at: [<
c025e73b>] dquot_claim_space+0x3b/0x1b0
but task is already holding lock:
(&meta_group_info[i]->alloc_sem){++++..}, at: [<
c02ce962>] ext4_mb_load_buddy+0xb2/0x370
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #3 (&meta_group_info[i]->alloc_sem){++++..}:
[<
c017d04b>] __lock_acquire+0xd7b/0x1260
[<
c017d5ea>] lock_acquire+0xba/0xd0
[<
c0527191>] down_read+0x51/0x90
[<
c02ce962>] ext4_mb_load_buddy+0xb2/0x370
[<
c02d0c1c>] ext4_mb_free_blocks+0x46c/0x870
[<
c029c9d3>] ext4_free_blocks+0x73/0x130
[<
c02c8cfc>] ext4_ext_truncate+0x76c/0x8d0
[<
c02a8087>] ext4_truncate+0x187/0x5e0
[<
c01e0f7b>] vmtruncate+0x6b/0x70
[<
c022ec02>] inode_setattr+0x62/0x190
[<
c02a2d7a>] ext4_setattr+0x25a/0x370
[<
c022ee81>] notify_change+0x151/0x340
[<
c021349d>] do_truncate+0x6d/0xa0
[<
c0221034>] may_open+0x1d4/0x200
[<
c022412b>] do_filp_open+0x1eb/0x910
[<
c021244d>] do_sys_open+0x6d/0x140
[<
c021258e>] sys_open+0x2e/0x40
[<
c0103100>] sysenter_do_call+0x12/0x32
-> #2 (&ei->i_data_sem){++++..}:
[<
c017d04b>] __lock_acquire+0xd7b/0x1260
[<
c017d5ea>] lock_acquire+0xba/0xd0
[<
c0527191>] down_read+0x51/0x90
[<
c02a5787>] ext4_get_blocks+0x47/0x450
[<
c02a74c1>] ext4_getblk+0x61/0x1d0
[<
c02a7a7f>] ext4_bread+0x1f/0xa0
[<
c02bcddc>] ext4_quota_write+0x12c/0x310
[<
c0262d23>] qtree_write_dquot+0x93/0x120
[<
c0261708>] v2_write_dquot+0x28/0x30
[<
c025d3fb>] dquot_commit+0xab/0xf0
[<
c02be977>] ext4_write_dquot+0x77/0x90
[<
c02be9bf>] ext4_mark_dquot_dirty+0x2f/0x50
[<
c025e321>] dquot_alloc_inode+0x101/0x180
[<
c029fec2>] ext4_new_inode+0x602/0xf00
[<
c02ad789>] ext4_create+0x89/0x150
[<
c0221ff2>] vfs_create+0xa2/0xc0
[<
c02246e7>] do_filp_open+0x7a7/0x910
[<
c021244d>] do_sys_open+0x6d/0x140
[<
c021258e>] sys_open+0x2e/0x40
[<
c0103100>] sysenter_do_call+0x12/0x32
-> #1 (&sb->s_type->i_mutex_key#7/4){+.+...}:
[<
c017d04b>] __lock_acquire+0xd7b/0x1260
[<
c017d5ea>] lock_acquire+0xba/0xd0
[<
c0526505>] mutex_lock_nested+0x65/0x2d0
[<
c0260c9d>] vfs_load_quota_inode+0x4bd/0x5a0
[<
c02610af>] vfs_quota_on_path+0x5f/0x70
[<
c02bc812>] ext4_quota_on+0x112/0x190
[<
c026345a>] sys_quotactl+0x44a/0x8a0
[<
c0103100>] sysenter_do_call+0x12/0x32
-> #0 (&s->s_dquot.dqptr_sem){++++..}:
[<
c017d361>] __lock_acquire+0x1091/0x1260
[<
c017d5ea>] lock_acquire+0xba/0xd0
[<
c0527191>] down_read+0x51/0x90
[<
c025e73b>] dquot_claim_space+0x3b/0x1b0
[<
c02cb95f>] ext4_mb_mark_diskspace_used+0x36f/0x380
[<
c02d210a>] ext4_mb_new_blocks+0x34a/0x530
[<
c02c83fb>] ext4_ext_get_blocks+0x122b/0x13c0
[<
c02a5966>] ext4_get_blocks+0x226/0x450
[<
c02a5ff3>] mpage_da_map_blocks+0xc3/0xaa0
[<
c02a6ed6>] ext4_da_writepages+0x506/0x790
[<
c01de272>] do_writepages+0x22/0x50
[<
c01d766d>] __filemap_fdatawrite_range+0x6d/0x80
[<
c01d7b9b>] filemap_flush+0x2b/0x30
[<
c02a40ac>] ext4_alloc_da_blocks+0x5c/0x60
[<
c029e595>] ext4_release_file+0x75/0xb0
[<
c0216b59>] __fput+0xf9/0x210
[<
c0216c97>] fput+0x27/0x30
[<
c02122dc>] filp_close+0x4c/0x80
[<
c014510e>] put_files_struct+0x6e/0xd0
[<
c01451b7>] exit_files+0x47/0x60
[<
c0146a24>] do_exit+0x144/0x710
[<
c0147028>] do_group_exit+0x38/0xa0
[<
c0159abc>] get_signal_to_deliver+0x2ac/0x410
[<
c0102849>] do_notify_resume+0xb9/0x890
[<
c01032d2>] work_notifysig+0x13/0x21
other info that might help us debug this:
3 locks held by write-truncate-/3465:
#0: (jbd2_handle){+.+...}, at: [<
c02e1f8f>] start_this_handle+0x38f/0x5c0
#1: (&ei->i_data_sem){++++..}, at: [<
c02a57f6>] ext4_get_blocks+0xb6/0x450
#2: (&meta_group_info[i]->alloc_sem){++++..}, at: [<
c02ce962>] ext4_mb_load_buddy+0xb2/0x370
stack backtrace:
Pid: 3465, comm: write-truncate- Not tainted 2.6.32-rc7 #18
Call Trace:
[<
c0524cb3>] ? printk+0x1d/0x22
[<
c017ac9a>] print_circular_bug+0xca/0xd0
[<
c017d361>] __lock_acquire+0x1091/0x1260
[<
c016bca2>] ? sched_clock_local+0xd2/0x170
[<
c0178fd0>] ? trace_hardirqs_off_caller+0x20/0xd0
[<
c017d5ea>] lock_acquire+0xba/0xd0
[<
c025e73b>] ? dquot_claim_space+0x3b/0x1b0
[<
c0527191>] down_read+0x51/0x90
[<
c025e73b>] ? dquot_claim_space+0x3b/0x1b0
[<
c025e73b>] dquot_claim_space+0x3b/0x1b0
[<
c02cb95f>] ext4_mb_mark_diskspace_used+0x36f/0x380
[<
c02d210a>] ext4_mb_new_blocks+0x34a/0x530
[<
c02c601d>] ? ext4_ext_find_extent+0x25d/0x280
[<
c02c83fb>] ext4_ext_get_blocks+0x122b/0x13c0
[<
c016bca2>] ? sched_clock_local+0xd2/0x170
[<
c016be60>] ? sched_clock_cpu+0x120/0x160
[<
c016beef>] ? cpu_clock+0x4f/0x60
[<
c0178fd0>] ? trace_hardirqs_off_caller+0x20/0xd0
[<
c052712c>] ? down_write+0x8c/0xa0
[<
c02a5966>] ext4_get_blocks+0x226/0x450
[<
c016be60>] ? sched_clock_cpu+0x120/0x160
[<
c016beef>] ? cpu_clock+0x4f/0x60
[<
c017908b>] ? trace_hardirqs_off+0xb/0x10
[<
c02a5ff3>] mpage_da_map_blocks+0xc3/0xaa0
[<
c01d69cc>] ? find_get_pages_tag+0x16c/0x180
[<
c01d6860>] ? find_get_pages_tag+0x0/0x180
[<
c02a73bd>] ? __mpage_da_writepage+0x16d/0x1a0
[<
c01dfc4e>] ? pagevec_lookup_tag+0x2e/0x40
[<
c01ddf1b>] ? write_cache_pages+0xdb/0x3d0
[<
c02a7250>] ? __mpage_da_writepage+0x0/0x1a0
[<
c02a6ed6>] ext4_da_writepages+0x506/0x790
[<
c016beef>] ? cpu_clock+0x4f/0x60
[<
c016bca2>] ? sched_clock_local+0xd2/0x170
[<
c016be60>] ? sched_clock_cpu+0x120/0x160
[<
c016be60>] ? sched_clock_cpu+0x120/0x160
[<
c02a69d0>] ? ext4_da_writepages+0x0/0x790
[<
c01de272>] do_writepages+0x22/0x50
[<
c01d766d>] __filemap_fdatawrite_range+0x6d/0x80
[<
c01d7b9b>] filemap_flush+0x2b/0x30
[<
c02a40ac>] ext4_alloc_da_blocks+0x5c/0x60
[<
c029e595>] ext4_release_file+0x75/0xb0
[<
c0216b59>] __fput+0xf9/0x210
[<
c0216c97>] fput+0x27/0x30
[<
c02122dc>] filp_close+0x4c/0x80
[<
c014510e>] put_files_struct+0x6e/0xd0
[<
c01451b7>] exit_files+0x47/0x60
[<
c0146a24>] do_exit+0x144/0x710
[<
c017b163>] ? lock_release_holdtime+0x33/0x210
[<
c0528137>] ? _spin_unlock_irq+0x27/0x30
[<
c0147028>] do_group_exit+0x38/0xa0
[<
c017babb>] ? trace_hardirqs_on+0xb/0x10
[<
c0159abc>] get_signal_to_deliver+0x2ac/0x410
[<
c0102849>] do_notify_resume+0xb9/0x890
[<
c0178fd0>] ? trace_hardirqs_off_caller+0x20/0xd0
[<
c017b163>] ? lock_release_holdtime+0x33/0x210
[<
c0165b50>] ? autoremove_wake_function+0x0/0x50
[<
c017ba54>] ? trace_hardirqs_on_caller+0x134/0x190
[<
c017babb>] ? trace_hardirqs_on+0xb/0x10
[<
c0300ba4>] ? security_file_permission+0x14/0x20
[<
c0215761>] ? vfs_write+0x131/0x190
[<
c0214f50>] ? do_sync_write+0x0/0x120
[<
c0103115>] ? sysenter_do_call+0x27/0x32
[<
c01032d2>] work_notifysig+0x13/0x21
CC: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Ben Hutchings [Wed, 28 Jul 2010 22:53:47 +0000 (23:53 +0100)]
ethtool: Fix potential user buffer overflow for ETHTOOL_{G, S}RXFH
commit
bf988435bd5b53529f4408a8efb1f433f6ddfda9 upstream.
struct ethtool_rxnfc was originally defined in 2.6.27 for the
ETHTOOL_{G,S}RXFH command with only the cmd, flow_type and data
fields. It was then extended in 2.6.30 to support various additional
commands. These commands should have been defined to use a new
structure, but it is too late to change that now.
Since user-space may still be using the old structure definition
for the ETHTOOL_{G,S}RXFH commands, and since they do not need the
additional fields, only copy the originally defined fields to and
from user-space.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Corey Minyard [Wed, 21 Jul 2010 13:39:22 +0000 (08:39 -0500)]
USB: FTDI: Add support for the RT System VX-7 radio programming cable
commit
fcc6cb789c77ffee31710eec64efeb25f2124f7a upstream.
RT Systems has put out bunch of ham radio cables based on the FT232RL
chip. Each cable type has a unique PID, this adds one for the Yaesu VX-7
radios.
Signed-off-by: Corey Minyard <minyard@acm.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Oliver Neukum [Wed, 14 Jul 2010 16:26:22 +0000 (18:26 +0200)]
USB: add quirk for Broadcom BT dongle
commit
63ab71deae67b031045bb28bf8cff45180089f8f upstream.
This device needs to be reset when resuming
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Oliver Neukum [Fri, 16 Jul 2010 15:36:26 +0000 (17:36 +0200)]
USB: sisusbvga: Fix for USB 3.0
commit
20a12f007feee1cfa761b431047271d1141d8031 upstream.
Super speed is also fast enough to let sisusbvga operate.
Therefor expand the checks.
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Paul Mortier [Fri, 9 Jul 2010 12:18:50 +0000 (13:18 +0100)]
USB: adds Artisman USB dongle to list of quirky devices
commit
47f19c0eedb377ad1ee8114f464d001ec5f96a69 upstream.
When an attempt is made to read the interface strings of the Artisman
Watchdog USB dongle (idVendor:idProduct 04b4:0526) an error is written
to the dmesg log (uhci_result_common: failed with status 440000) and the
dongle resets itself, resulting in a disconnect/reconnect loop.
Adding the dongle to the list of devices in quirks.c, with the same
quirk Alan Stern's previous patch for the Saitek Cyborg Gold 3D
joystick, stops the device from resetting and allows it to be used with
no problems.
Signed-off-by: Paul Mortier <mortier@btinternet.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dennis Jansen [Fri, 9 Jul 2010 20:03:53 +0000 (22:03 +0200)]
USB: option: Add support for AMOI Skypephone S2
commit
7595931c986f50b1e197ce7b881563e36a7d041e upstream.
usbserial: Add AMOI Skypephone S2 support.
This patch adds support for the AMOI Skypephone S2 to the usbserial module.
Tested-by: Dennis Jansen <Dennis.Jansen@web.de>
Signed-off-by: Dennis Jansen <Dennis.Jansen@web.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Colin Leitner [Thu, 1 Jul 2010 08:49:55 +0000 (10:49 +0200)]
USB: ftdi_sio: support for Signalyzer tools based on FTDI chips
commit
77dbd74e16b566e9d5eeb4be18ae3ee7d5902bd3 upstream.
ftdi_sio: support for Signalyzer tools based on FTDI chips
This patch adds support for the Xverve Signalyzers.
Signed-off-by: Colin Leitner <colin.leitner@googlemail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
august huber [Mon, 28 Jun 2010 18:46:05 +0000 (11:46 -0700)]
USB: Add PID for Sierra 250U to drivers/usb/serial/sierra.c
commit
9d72c81d657340e54a260a3b621f4a9f5b33829c upstream.
Add VID/PID for Sierra Wireless 250U USB dongle to sierra.c
Allows use of 3G radio only
Signed-off-by: August Huber <gus@pbx.org>
Cc: Elina Pasheva <epasheva@sierrawireless.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Ömer Sezgin Ugurlu [Mon, 28 Jun 2010 16:01:58 +0000 (19:01 +0300)]
USB: option: add support for 1da5:4518
commit
646d90e2b925578abef5c45853e0b166b6a450bf upstream.
Signed-off-by: Omer Sezgin Ugurlu <omer.ugurlu@a-kent.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jon Povey [Mon, 14 Jun 2010 10:42:10 +0000 (19:42 +0900)]
USB: g_serial: fix tty cleanup on unload
commit
b23097b793081358a6d943263c91bae4c955c4e3 upstream.
Call put_tty_driver() in cleanup function, to fix Oops when trying to open
gadget serial char device after module unload.
Signed-off-by: Jon Povey <jon.povey@racelogic.co.uk>
Acked-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jon Povey [Mon, 14 Jun 2010 10:41:04 +0000 (19:41 +0900)]
USB: g_serial: don't set low_latency flag
commit
44a0c0190b500ee6bcfc0976fe540f65dee2cd67 upstream.
No longer set low_latency flag as it causes this warning backtrace:
WARNING: at kernel/mutex.c:207 __mutex_lock_slowpath+0x6c/0x288()
Fix associated locking and wakeups.
Signed-off-by: Jon Povey <jon.povey@racelogic.co.uk>
Cc: Maulik Mankad <x0082077@ti.com>
Acked-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Alan Stern [Tue, 22 Jun 2010 20:14:48 +0000 (16:14 -0400)]
USB: obey the sysfs power/wakeup setting
commit
48826626263d4a61d06fd8c5805da31f925aefa0 upstream.
This patch (as1403) is a partial reversion of an earlier change
(commit
5f677f1d45b2bf08085bbba7394392dfa586fa8e "USB: fix remote
wakeup settings during system sleep"). After hearing from a user, I
realized that remote wakeup should be enabled during system sleep
whenever userspace allows it, and not only if a driver requests it
too.
Indeed, there could be a device with no driver, that does nothing but
generate a wakeup request when the user presses a button. Such a
device should be allowed to do its job.
The problem fixed by the earlier patch -- device generating a wakeup
request for no reason, causing system suspend to abort -- was also
addressed by a later patch ("USB: don't enable remote wakeup by
default", accepted but not yet merged into mainline). The device
won't be able to generate the bogus wakeup requests because it will be
disabled for remote wakeup by default. Hence this reversion will not
re-introduce any old problems.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Pavel Roskin [Wed, 10 Mar 2010 04:11:07 +0000 (23:11 -0500)]
Staging: rtl8192su: add USB ID for 0bda:8171
commit
c0087580b8d414f6874cfe93d2653212842fcb44 upstream.
Signed-off-by: Pavel Roskin <proski@gnu.org>
Cc: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Stephane Glondu [Thu, 17 Dec 2009 14:41:23 +0000 (15:41 +0100)]
staging: rtl8192su: add USB VID/PID for HWNUm-300
commit
488d3749620779ab2668c0dba2962836e51e3cd6 upstream.
The Hercules Wireless N USB mini (HWNUm-300) uses the RTL8191S chipset
and seems to work with this driver.
Signed-off-by: Stephane Glondu <steph@glondu.net>
Cc: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Stefano Stabellini [Wed, 21 Jul 2010 17:32:37 +0000 (18:32 +0100)]
x86: Do not try to disable hpet if it hasn't been initialized before
commit
ff4878089e1eaeac79d57878ad4ea32910fb4037 upstream.
hpet_disable is called unconditionally on machine reboot if hpet support
is compiled in the kernel.
hpet_disable only checks if the machine is hpet capable but doesn't make
sure that hpet has been initialized.
[ tglx: Made it a one liner and removed the redundant hpet_address check ]
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Venkatesh Pallipadi <venki@google.com>
LKML-Reference: <alpine.DEB.2.00.
1007211726240.22235@kaball-desktop>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Nicolas Pitre [Wed, 14 Jul 2010 04:21:22 +0000 (05:21 +0100)]
ARM: 6226/1: fix kprobe bug in ldr instruction emulation
commit
0ebe25f90cd99bb1bcf622ec8a841421d48380d6 upstream.
From: Bin Yang <bin.yang@marvell.com>
Signed-off-by: Bin Yang <bin.yang@marvell.com>
Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Catalin Marinas [Thu, 1 Jul 2010 12:21:47 +0000 (13:21 +0100)]
ARM: 6201/1: RealView: Do not use outer_sync() on ARM11MPCore boards with L220
commit
2503a5ecd86c002506001eba432c524ea009fe7f upstream.
RealView boards with certain revisions of the L220 cache controller (ARM11*
processors only) may have issues (hardware deadlock) with the recent changes to
the mb() barrier implementation (DSB followed by an L2 cache sync). The patch
redefines the RealView ARM11MPCore mandatory barriers without the outer_sync()
call.
Tested-by: Linus Walleij <linus.walleij@stericsson.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dmitry Torokhov [Wed, 21 Jul 2010 03:25:35 +0000 (20:25 -0700)]
Input: twl40300-keypad - fix handling of "all ground" rows
commit
3fea60261e73dbf4a51130d40cafcc8465b0f2c3 upstream.
The Nokia RX51 board code (arch/arm/mach-omap2/board-rx51-peripherals.c)
defines a key map for the matrix keypad keyboard. The hardware seems to
use all of the 8 rows and 8 columns of the keypad, although not all
possible locations are used.
The TWL4030 supports keypads with at most 8 rows and 8 columns. Most keys
are defined with a row and column number between 0 and 7, except
KEY(0xff, 2, KEY_F9),
KEY(0xff, 4, KEY_F10),
KEY(0xff, 5, KEY_F11),
which represent keycodes that should be emitted when entire row is
connected to the ground. since the driver handles this case as if we
had an extra column in the key matrix. Unfortunately we do not allocate
enough space and end up owerwriting some random memory.
Reported-and-tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Kamal Mostafa [Mon, 19 Jul 2010 18:00:52 +0000 (11:00 -0700)]
Input: i8042 - add Gigabyte Spring Peak to dmi_noloop_table
commit
3e1bbc8d5018a05c0793c8a32b777a1396eb4414 upstream.
Gigabyte "Spring Peak" notebook indicates wrong chassis-type, tripping up
i8042 and breaking the touchpad. Add this model to i8042_dmi_noloop_table[]
to resolve.
BugLink: https://bugs.launchpad.net/bugs/580664
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Or Gerlitz [Sun, 6 Jun 2010 04:59:16 +0000 (04:59 +0000)]
IPoIB: Fix world-writable child interface control sysfs attributes
commit
7a52b34b07122ff5f45258d47f260f8a525518f0 upstream.
Sumeet Lahorani <sumeet.lahorani@oracle.com> reported that the IPoIB
child entries are world-writable; however we don't want ordinary users
to be able to create and destroy child interfaces, so fix them to be
writable only by root.
Signed-off-by: Or Gerlitz <ogerlitz@voltaire.com>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Yinghai Lu [Thu, 15 Jul 2010 07:00:59 +0000 (00:00 -0700)]
x86: Fix x2apic preenabled system with kexec
commit
fd19dce7ac07973f700b0f13fb7f94b951414a4c upstream.
Found one x2apic system kexec loop test failed
when CONFIG_NMI_WATCHDOG=y (old) or CONFIG_LOCKUP_DETECTOR=y (current tip)
first kernel can kexec second kernel, but second kernel can not kexec third one.
it can be duplicated on another system with BIOS preenabled x2apic.
First kernel can not kexec second kernel.
It turns out, when kernel boot with pre-enabled x2apic, it will not execute
disable_local_APIC on shutdown path.
when init_apic_mappings() is called in setup_arch, it will skip setting of
apic_phys when x2apic_mode is set. ( x2apic_mode is much early check_x2apic())
Then later, disable_local_APIC() will bail out early because !apic_phys.
So check !x2apic_mode in x2apic_mode in disable_local_APIC with !apic_phys.
another solution could be updating init_apic_mappings() to set apic_phys even
for preenabled x2apic system. Actually even for x2apic system, that lapic
address is mapped already in early stage.
BTW: is there any x2apic preenabled system with apicid of boot cpu > 255?
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
LKML-Reference: <
4C3EB22B.
3000701@kernel.org>
Acked-by: Suresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Mark Brown [Sat, 17 Jul 2010 13:20:17 +0000 (14:20 +0100)]
ASoC: Remove duplicate AUX definition from WM8776
commit
3c0709396df0869786f83e4b2d2d687c70ee886d upstream.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@slimlogic.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Marek Szyprowski [Tue, 20 Jul 2010 20:24:33 +0000 (13:24 -0700)]
sdhci-s3c: add missing remove function
commit
9d51a6b2487724e8713cd2794cf09ffeee5f6932 upstream.
System will crash sooner or later once the memory with the code of the
s3c-sdhci.ko module is reused for something else. I really have no idea
how the lack of remove function went unnoticed into the mainline code.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Ben Hutchings [Mon, 28 Jun 2010 08:44:07 +0000 (08:44 +0000)]
ethtool: Fix potential kernel buffer overflow in ETHTOOL_GRXCLSRLALL
commit
db048b69037e7fa6a7d9e95a1271a50dc08ae233 upstream.
On a 32-bit machine, info.rule_cnt >= 0x40000000 leads to integer
overflow and the buffer may be smaller than needed. Since
ETHTOOL_GRXCLSRLALL is unprivileged, this can presumably be used for at
least denial of service.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Joakim Tjernlund [Tue, 29 Jun 2010 22:05:34 +0000 (15:05 -0700)]
rtc: fix ds1388 time corruption
commit
96fc3a45ea073136566f3c2676cad52f8b39a7df upstream.
The ds1307 driver misreads the ds1388 registers when checking for 12 or 24
hour mode. Instead of checking the hour register it reads the minute
register. Therefore the driver thinks minutes >= 40 has the 12HR bit set
and resets the minute register by zeroing the high bits. This results in
minutes are reset to 0-9, jumping back in time 40 or 50 minutes. The time
jump is also written back to the RTC.
Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
Cc: Wan ZongShun <mcuos.com@gmail.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Paul Gortmaker <p_gortmaker@yahoo.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Ilpo Järvinen [Mon, 19 Jul 2010 01:16:18 +0000 (01:16 +0000)]
tcp: fix crash in tcp_xmit_retransmit_queue
commit
45e77d314585869dfe43c82679f7e08c9b35b898 upstream.
It can happen that there are no packets in queue while calling
tcp_xmit_retransmit_queue(). tcp_write_queue_head() then returns
NULL and that gets deref'ed to get sacked into a local var.
There is no work to do if no packets are outstanding so we just
exit early.
This oops was introduced by
08ebd1721ab8fd (tcp: remove tp->lost_out
guard to make joining diff nicer).
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
Reported-by: Lennart Schulte <lennart.schulte@nets.rwth-aachen.de>
Tested-by: Lennart Schulte <lennart.schulte@nets.rwth-aachen.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Doug Kehn [Thu, 15 Jul 2010 01:02:16 +0000 (18:02 -0700)]
net/core: neighbour update Oops
commit
91a72a70594e5212c97705ca6a694bd307f7a26b upstream.
When configuring DMVPN (GRE + openNHRP) and a GRE remote
address is configured a kernel Oops is observed. The
obserseved Oops is caused by a NULL header_ops pointer
(neigh->dev->header_ops) in neigh_update_hhs() when
void (*update)(struct hh_cache*, const struct net_device*, const unsigned char *)
= neigh->dev->header_ops->cache_update;
is executed. The dev associated with the NULL header_ops is
the GRE interface. This patch guards against the
possibility that header_ops is NULL.
This Oops was first observed in kernel version 2.6.26.8.
Signed-off-by: Doug Kehn <rdkehn@yahoo.com>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Mikulas Patocka [Tue, 6 Apr 2010 23:43:33 +0000 (16:43 -0700)]
ide: Fix IDE taskfile with cfq scheduler
commit
720fc22a7af79d91ec460c80efa92c65c12d105e upstream.
When ide taskfile access is being used (for example with hdparm --security
commands) and cfq scheduler is selected, the scheduler crashes on BUG in
cfq_put_request.
The reason is that the cfq scheduler is tracking counts of read and write
requests separately; the ide-taskfile subsystem allocates a read request and
then flips the flag to make it a write request. The counters in cfq will
mismatch.
This patch changes ide-taskfile to allocate the READ or WRITE request as
required and don't change the flag later.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Sergei Shtylyov [Tue, 11 May 2010 07:08:03 +0000 (00:08 -0700)]
cmd640: fix kernel oops in test_irq() method
commit
a9ddabc52ce3757a4331d6c1e8bf4065333cc51b upstream.
When implementing the test_iqr() method, I forgot that this driver is not an
ordinary PCI driver and also needs to support VLB variant of the chip. Moreover,
'hwif->dev' should be NULL, potentially causing oops in pci_read_config_byte().
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dongdong Deng [Thu, 17 Jun 2010 03:13:40 +0000 (11:13 +0800)]
serial: cpm_uart: implement the cpm_uart_early_write() function for console poll
commit
8cd774ad30c22b9d89823f1f05d845f4cdaba9e8 upstream.
The cpm_uart_early_write() function which was used for console poll
isn't implemented in the cpm uart driver.
Implementing this function both fixes the build when CONFIG_CONSOLE_POLL
is set and allows kgdboc to work via the cpm uart.
Signed-off-by: Dongdong Deng <dongdong.deng@windriver.com>
Reviewed-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Thomas Gleixner [Mon, 7 Jun 2010 15:53:51 +0000 (17:53 +0200)]
genirq: Deal with desc->set_type() changing desc->chip
commit
4673247562e39a17e09440fa1400819522ccd446 upstream.
The set_type() function can change the chip implementation when the
trigger mode changes. That might result in using an non-initialized
irq chip when called from __setup_irq() or when called via
set_irq_type() on an already enabled irq.
The set_irq_type() function should not be called on an enabled irq,
but because we forgot to put a check into it, we have a bunch of users
which grew the habit of doing that and it never blew up as the
function is serialized via desc->lock against all users of desc->chip
and they never hit the non-initialized irq chip issue.
The easy fix for the __setup_irq() issue would be to move the
irq_chip_set_defaults(desc->chip) call after the trigger setting to
make sure that a chip change is covered.
But as we have already users, which do the type setting after
request_irq(), the safe fix for now is to call irq_chip_set_defaults()
from __irq_set_trigger() when desc->set_type() changed the irq chip.
It needs a deeper analysis whether we should refuse to change the chip
on an already enabled irq, but that'd be a large scale change to fix
all the existing users. So that's neither stable nor 2.6.35 material.
Reported-by: Esben Haabendal <eha@doredevelopment.dk>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linuxppc-dev <linuxppc-dev@ozlabs.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>