03 Apr, 2012
40 commits
-
commit f35b431dde39fb40944d1024f08d88fbf04a3193 upstream.
The ARM IP revisions in Tegra are:
Tegra20: CPU r1p1, PL310 r2p0
Tegra30: CPU A01=r2p7/>=A02=r2p9, NEON r2p3-50, PL310 r3p1-50Based on work by Olof Johansson, although the actual list of errata is
somewhat different here, since I added a bunch more and removed one PL310
erratum that doesn't seem applicable.Signed-off-by: Stephen Warren
Signed-off-by: Olof Johansson
Signed-off-by: Greg Kroah-Hartman -
commit b18dafc86bb879d2f38a1743985d7ceb283c2f4d upstream.
In d_materialise_unique() there are 3 subcases to the 'aliased dentry'
case; in two subcases the inode i_lock is properly released but this
does not occur in the -ELOOP subcase.This seems to have been introduced by commit 1836750115f2 ("fix loop
checks in d_materialise_unique()").Signed-off-by: Michel Lespinasse
[ Added a comment, and moved the unlock to where we generate the -ELOOP,
which seems to be more natural.You probably can't actually trigger this without a buggy network file
server - d_materialize_unique() is for finding aliases on non-local
filesystems, and the d_ancestor() case is for a hardlinked directory
loop.But we should be robust in the case of such buggy servers anyway. ]
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 31d4f3a2f3c73f279ff96a7135d7202ef6833f12 upstream.
Explicitly test for an extent whose length is zero, and flag that as a
corrupted extent.This avoids a kernel BUG_ON assertion failure.
Tested: Without this patch, the file system image found in
tests/f_ext_zero_len/image.gz in the latest e2fsprogs sources causes a
kernel panic. With this patch, an ext4 file system error is noted
instead, and the file system is marked as being corrupted.https://bugzilla.kernel.org/show_bug.cgi?id=42859
Signed-off-by: "Theodore Ts'o"
Signed-off-by: Greg Kroah-Hartman -
commit 491caa43639abcffaa645fbab372a7ef4ce2975c upstream.
The following command line will leave the aio-stress process unkillable
on an ext4 file system (in my case, mounted on /mnt/test):aio-stress -t 20 -s 10 -O -S -o 2 -I 1000 /mnt/test/aiostress.3561.4 /mnt/test/aiostress.3561.4.20 /mnt/test/aiostress.3561.4.19 /mnt/test/aiostress.3561.4.18 /mnt/test/aiostress.3561.4.17 /mnt/test/aiostress.3561.4.16 /mnt/test/aiostress.3561.4.15 /mnt/test/aiostress.3561.4.14 /mnt/test/aiostress.3561.4.13 /mnt/test/aiostress.3561.4.12 /mnt/test/aiostress.3561.4.11 /mnt/test/aiostress.3561.4.10 /mnt/test/aiostress.3561.4.9 /mnt/test/aiostress.3561.4.8 /mnt/test/aiostress.3561.4.7 /mnt/test/aiostress.3561.4.6 /mnt/test/aiostress.3561.4.5 /mnt/test/aiostress.3561.4.4 /mnt/test/aiostress.3561.4.3 /mnt/test/aiostress.3561.4.2
This is using the aio-stress program from the xfstests test suite.
That particular command line tells aio-stress to do random writes to
20 files from 20 threads (one thread per file). The files are NOT
preallocated, so you will get writes to random offsets within the
file, thus creating holes and extending i_size. It also opens the
file with O_DIRECT and O_SYNC.On to the problem. When an I/O requires unwritten extent conversion,
it is queued onto the completed_io_list for the ext4 inode. Two code
paths will pull work items from this list. The first is the
ext4_end_io_work routine, and the second is ext4_flush_completed_IO,
which is called via the fsync path (and O_SYNC handling, as well).
There are two issues I've found in these code paths. First, if the
fsync path beats the work routine to a particular I/O, the work
routine will free the io_end structure! It does not take into account
the fact that the io_end may still be in use by the fsync path. I've
fixed this issue by adding yet another IO_END flag, indicating that
the io_end is being processed by the fsync path.The second problem is that the work routine will make an assignment to
io->flag outside of the lock. I have witnessed this result in a hang
at umount. Moving the flag setting inside the lock resolved that
problem.The problem was introduced by commit b82e384c7b ("ext4: optimize
locking for end_io extent conversion"), which first appeared in 3.2.
As such, the fix should be backported to that release (probably along
with the unwritten extent conversion race fix).Signed-off-by: Jeff Moyer
Signed-off-by: "Theodore Ts'o"
Signed-off-by: Greg Kroah-Hartman -
commit 266991b13890049ee1a6bb95b9817f06339ee3d7 upstream.
The following comment in ext4_end_io_dio caught my attention:
/* XXX: probably should move into the real I/O completion handler */
inode_dio_done(inode);The truncate code takes i_mutex, then calls inode_dio_wait. Because the
ext4 code path above will end up dropping the mutex before it is
reacquired by the worker thread that does the extent conversion, it
seems to me that the truncate can happen out of order. Jan Kara
mentioned that this might result in error messages in the system logs,
but that should be the extent of the "damage."The fix is pretty straight-forward: don't call inode_dio_done until the
extent conversion is complete.Reviewed-by: Jan Kara
Signed-off-by: Jeff Moyer
Signed-off-by: "Theodore Ts'o"
Signed-off-by: Greg Kroah-Hartman -
commit 3d2b158262826e8b75bbbfb7b97010838dd92ac7 upstream.
Ext4 does not support data journalling with delayed allocation enabled.
We even do not allow to mount the file system with delayed allocation
and data journalling enabled, however it can be set via FS_IOC_SETFLAGS
so we can hit the inode with EXT4_INODE_JOURNAL_DATA set even on file
system mounted with delayed allocation (default) and that's where
problem arises. The easies way to reproduce this problem is with the
following set of commands:mkfs.ext4 /dev/sdd
mount /dev/sdd /mnt/test1
dd if=/dev/zero of=/mnt/test1/file bs=1M count=4
chattr +j /mnt/test1/file
dd if=/dev/zero of=/mnt/test1/file bs=1M count=4 conv=notrunc
chattr -j /mnt/test1/fileAdditionally it can be reproduced quite reliably with xfstests 272 and
269. In fact the above reproducer is a part of test 272.To fix this we should ignore the EXT4_INODE_JOURNAL_DATA inode flag if
the file system is mounted with delayed allocation. This can be easily
done by fixing ext4_should_*_data() functions do ignore data journal
flag when delalloc is set (suggested by Ted). We also have to set the
appropriate address space operations for the inode (again, ignoring data
journal flag if delalloc enabled).Additionally this commit introduces ext4_inode_journal_mode() function
because ext4_should_*_data() has already had a lot of common code and
this change is putting it all into one function so it is easier to
read.Successfully tested with xfstests in following configurations:
delalloc + data=ordered
delalloc + data=writeback
data=journal
nodelalloc + data=ordered
nodelalloc + data=writeback
nodelalloc + data=journalSigned-off-by: Lukas Czerner
Signed-off-by: "Theodore Ts'o"
Signed-off-by: Greg Kroah-Hartman -
commit 15291164b22a357cb211b618adfef4fa82fc0de3 upstream.
journal_unmap_buffer()'s zap_buffer: code clears a lot of buffer head
state ala discard_buffer(), but does not touch _Delay or _Unwritten as
discard_buffer() does.This can be problematic in some areas of the ext4 code which assume
that if they have found a buffer marked unwritten or delay, then it's
a live one. Perhaps those spots should check whether it is mapped
as well, but if jbd2 is going to tear down a buffer, let's really
tear it down completely.Without this I get some fsx failures on sub-page-block filesystems
up until v3.2, at which point 4e96b2dbbf1d7e81f22047a50f862555a6cb87cb
and 189e868fa8fdca702eb9db9d8afc46b5cb9144c9 make the failures go
away, because buried within that large change is some more flag
clearing. I still think it's worth doing in jbd2, since
->invalidatepage leads here directly, and it's the right place
to clear away these flags.Signed-off-by: Eric Sandeen
Signed-off-by: "Theodore Ts'o"
Signed-off-by: Greg Kroah-Hartman -
commit 05b4877f6a4f1ba4952d1222213d262bf8c132b7 upstream.
If create_basic_memory_bitmaps() fails, usermodehelpers are not re-enabled
before returning. Fix this. And while at it, reword the goto labels so that
they look more meaningful.Signed-off-by: Srivatsa S. Bhat
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman -
commit 9a3ba432330e504ac61ff0043dbdaba7cea0e35a upstream.
Prevent the state manager from filling up system logs when recovery
fails on the server.Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman -
commit 073863432f7eaa23c7c09733414d4be2eabf5eef upstream.
When this driver was upgraded to the vendor 20100831 version in
commit 93c55dda092c7 et al,, one listhead initialization was missed.
This broke complete operation of the driver whenever AP mode was
enabled. This fixes https://bugs.archlinux.org/task/27996.The configuration parameter R8712_AP is misleading as the driver cannot
function as an AP without a heavily hacked version of hostapd. Thus, it
makes sense to remove the parameter; however the code and data configured
for the option is left in.Signed-off-by: Larry Finger
Signed-off-by: Greg Kroah-Hartman -
commit b0302aba812bcc39291cdab9ad7e37008f352a91 upstream.
This patch addresses a kernel bugzilla report and two recent mail threads.
The kernel bugzilla report is https://bugzilla.kernel.org/show_bug.cgi?id=42632,
which reports a udev timeout on boot.The first mail thread, which was on LKML (http://lkml.indiana.edu/hypermail/
linux/kernel/1112.3/00965.html) was for a WARNING that occurs after a
suspend/resume cycle for rtl8192cu.The scond mail thread (http://marc.info/?l=linux-wireless&m=132655490826766&w=2)
concerned changes in udev that break drivers that delay while firmware is loaded
on modprobe.This patch converts all rtlwifi-based drivers to use the asynchronous firmware
loading mechanism. Drivers rtl8192ce, rtl8192cu and rtl8192de share a common
callback routine. Driver rtl8192se needs different handling of the firmware,
thus it has its own code.Signed-off-by: Larry Finger
Signed-off-by: John W. Linville
Signed-off-by: Greg Kroah-Hartman -
Commit 57d13370cfaf6017c68981e66ff5b3bf20a2705c upstream.
Make the MTU2 clocksource driver mark its device as "always on"
using pm_genpd_dev_always_on() to protect it from surprise power
removals.Signed-off-by: Rafael J. Wysocki
Tested-by: Simon Horman
Acked-by: Paul Mundt
Signed-off-by: Greg Kroah-Hartman -
Commit 615a445f7f8a077c145e737864ae59a4d8717882 upstream.
Make the CMT clocksource driver mark its device as "always on"
using pm_genpd_dev_always_on() to protect it from surprise power
removals.Signed-off-by: Rafael J. Wysocki
Tested-by: Simon Horman
Acked-by: Paul Mundt
Signed-off-by: Greg Kroah-Hartman -
Commit 2ee619f9487c2acc1efdf2c78e68e2bd51b635fa upstream.
Make the TMU clocksource driver mark its device as "always on"
using pm_genpd_dev_always_on() to protect it from surprise power
removals and make sh7372_add_standard_devices() add TMU devices on
sh7372 to the A4R power domain so that their "always on" flags
are taken into account as appropriate.Signed-off-by: Rafael J. Wysocki
Tested-by: Simon Horman
Acked-by: Paul Mundt
Signed-off-by: Greg Kroah-Hartman -
This is a backport of mainline commit
1e78a0c7fc92aee076965d516cf54475c39e9894.The TMU device on the Mackerel board belongs to the A4R power domain
and loses power when the domain is turned off. Unfortunately, the
TMU driver is not prepared to cope with such situations and crashes
the system when that happens. To work around this problem introduce
a new helper function, pm_genpd_dev_always_on(), allowing a device
driver to mark its device as "always on" in case it belongs to a PM
domain, which will make the generic PM domains core code avoid
powering off the domain containing the device, both at run time and
during system suspend.Signed-off-by: Rafael J. Wysocki
Tested-by: Simon Horman
Acked-by: Paul Mundt
Signed-off-by: Greg Kroah-Hartman -
This is a backport of mainline commit
18dd2ece3cde14cfd42e95a89eb14016699a5f15.Power domains that were off before hibernation shouldn't be turned on
during device restore, so prevent that from happening.This change fixed up mainline commit
65533bbf63b4f37723fdfedc73d0653958973323PM / Domains: Fix hibernation restore of devices, v2
that didn't include it by mistake.
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman -
This is a backport of mainline commit
65533bbf63b4f37723fdfedc73d0653958973323.During resume from hibernation pm_genpd_restore_noirq() should only
power off domains whose suspend_power_off flags are set once and
not every time it is called for a device in the given domain.
Moreover, it shouldn't decrement genpd->suspended_count, because
that field is not touched during device freezing and therefore it is
always equal to 0 when pm_genpd_restore_noirq() runs for the first
device in the given domain.This means pm_genpd_restore_noirq() may use genpd->suspended_count
to determine whether or not it it has been called for the domain in
question already in this cycle (it only needs to increment that
field every time it runs for this purpose) and whether or not it
should check if the domain needs to be powered off. For that to
work, though, pm_genpd_prepare() has to clear genpd->suspended_count
when it runs for the first device in the given domain (in which case
that flag need not be cleared during domain initialization).Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman -
commit 3be5bb71fbf18f83cb88b54a62a78e03e5a4f30a upstream.
Remove unnecessary register access in mxl111sf_ep6_streaming_ctrl()
This code breaks driver operation in kernel 3.3 and later, although
it works properly in 3.2 Disable register access to 0x12 for now.Signed-off-by: Michael Krufky
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit 9ab2393fc3e460cd2040de1483918eb17abb822f upstream.
The D1F5 revision of the WinTV HVR-1900 uses a tda18271c2 tuner
instead of a tda18271c1 tuner as used in revision D1E9. To
account for this, we must hardcode the frontend configuration
to use the same IF frequency configuration for both revisions
of the device.6MHz DVB-T is unaffected by this issue, as the recommended
IF Frequency configuration for 6MHz DVB-T is the same on both
c1 and c2 revisions of the tda18271 tuner.Signed-off-by: Michael Krufky
Cc: Mike Isely
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit ef3d2dc366c8c32d58dbbf9898cfd4f853ff8fe0 upstream.
The au8522 driver programs the tuner after programming the demodulator,
but the tuner should be programmed first. This patch fixes this behavior.EDIT: Apparantly Devin created a similar patch some time ago, but hasn't
submitted it for merge. I never saw his patch, but I thank him anyhow
for his efforts. In addition, Devin pointed out a flaw in my patch:This newly generated patch takes Devin's comments into account.
Thanks-to: Devin Heitmueller
Signed-off-by: Michael Krufky
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit 2b49fad59513b07f976c9711b99f93ae74d081c5 upstream.
Commit b2a29b578d9c21b2e5c88020f830d3c42115c51d sets accidentally
supported delivery systems as DVB-T/T2 whilst it should be
DVB-S/S2. Due to that frontend cannot be used at all.Reported-by: Jiří Zelenka
Signed-off-by: Antti Palosaari
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit abf9d005375d6c6160cc9c17e5dcac32e412c8dc upstream.
This patch fixes a regression in kernel 3.3 due to this patch:
http://patchwork.linuxtv.org/patch/8332/
That patch changes "#pragma pack(1)" with "__packed" attributes, but it is not
complete. In fact, in the as102 driver there are a lot of structs/unions
defined inside other structs/unions.
When the "__packed" attribute is applied only on the external struct, it will
not affect the internal struct definitions.
So the regression is fixed by specifiying the "__packed" attribute also on the
internal structs.This patch should go into 3.3, as it fixes a regression introduced in the new
kernel version.Signed-off-by: Gianluca Gennari
Signed-off-by: Ryley Angus
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit 34817174fca0c5512c2d5b6ea0fc37a0337ce1d8 upstream.
The error handling in lgdt3303_read_status() and lgdt330x_read_ucblocks()
doesn't work, because i2c_read_demod_bytes() returns a u8 and (err < 0)
is always false.err = i2c_read_demod_bytes(state, 0x58, buf, 1);
if (err < 0)
return err;Change the return type of i2c_read_demod_bytes() to int. Also change
the return value on error to -EIO to make (err < 0) work.Signed-off-by: Xi Wang
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit fc0900cbda9243957d812cd6b4cc87965f9fe75f upstream.
Wrong bit was used for sign extension which caused wrong end results.
Thanks to Andre for spotting this bug.Reported-by: Andre Przywara
Signed-off-by: Andreas Herrmann
Acked-by: Guenter Roeck
Signed-off-by: Jean Delvare
Signed-off-by: Greg Kroah-Hartman -
commit 4e474a00d7ff746ed177ddae14fa8b2d4bad7a00 upstream.
Protect code accessing ctl_table by grabbing the header with grab_header()
and after releasing with sysctl_head_finish(). This is needed if poll()
is called in entries created by modules: currently only hostname and
domainname support poll(), but this bug may be triggered when/if modules
use it and if user called poll() in a file that doesn't support it.Dave Jones reported the following when using a syscall fuzzer while
hibernating/resuming:RIP: 0010:[] [] proc_sys_poll+0x4e/0x90
RAX: 0000000000000145 RBX: ffff88020cab6940 RCX: 0000000000000000
RDX: ffffffff81233df0 RSI: 6b6b6b6b6b6b6b6b RDI: ffff88020cab6940
[ ... ]
Code: 00 48 89 fb 48 89 f1 48 8b 40 30 4c 8b 60 e8 b8 45 01 00 00 49 83
7c 24 28 00 74 2e 49 8b 74 24 30 48 85 f6 74 24 48 85 c9 75 32 16
b8 45 01 00 00 48 63 d2 49 39 d5 74 10 8b 06 48 98 48 89If an entry goes away while we are polling() it, ctl_table may not exist
anymore.Reported-by: Dave Jones
Signed-off-by: Lucas De Marchi
Cc: Al Viro
Cc: Linus Torvalds
Cc: Alexey Dobriyan
Signed-off-by: Andrew Morton
Signed-off-by: Eric W. Biederman
Signed-off-by: Greg Kroah-Hartman -
commit 9ddd592a191b32f2ee6c4b6ed2bd52665c3a49f5 upstream.
Unfortunatly the interrupts for the event log and the
peripheral page-faults are only enabled at boot but not
re-enabled at resume. Fix that.Signed-off-by: Joerg Roedel
Signed-off-by: Greg Kroah-Hartman -
commit cebd5fa4d3046d5b43ce1836a0120612822a7fb0 upstream.
Fix the following section warning in drivers/iommu/amd_iommu.c :
WARNING: vmlinux.o(.text+0x526e77): Section mismatch in reference from the function prealloc_protection_domains() to the function .init.text:alloc_passthrough_domain()
The function prealloc_protection_domains() references
the function __init alloc_passthrough_domain().
This is often because prealloc_protection_domains lacks a __init
annotation or the annotation of alloc_passthrough_domain is wrong.Signed-off-by: Steffen Persvold
Signed-off-by: Joerg Roedel
Signed-off-by: Greg Kroah-Hartman -
commit 1b26c9b334044cff6d1d2698f2be41bc7d9a0864 upstream.
The namespace cleanup path leaks a dentry which holds a reference count
on a network namespace. Keeping that network namespace from being freed
when the last user goes away. Leaving things like vlan devices in the
leaked network namespace.If you use ip netns add for much real work this problem becomes apparent
pretty quickly. It light testing the problem hides because frequently
you simply don't notice the leak.Use d_set_d_op() so that DCACHE_OP_* flags are set correctly.
This issue exists back to 3.0.
Acked-by: "Eric W. Biederman"
Reported-by: Justin Pettit
Signed-off-by: Pravin B Shelar
Signed-off-by: Jesse Gross
Cc: David Miller
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 29a2e2836ff9ea65a603c89df217f4198973a74f upstream.
The problem occurs on !CONFIG_VM86 kernels [1] when a kernel-mode task
returns from a system call with a pending signal.A real-life scenario is a child of 'khelper' returning from a failed
kernel_execve() in ____call_usermodehelper() [ kernel/kmod.c ].
kernel_execve() fails due to a pending SIGKILL, which is the result of
"kill -9 -1" (at least, busybox's init does it upon reboot).The loop is as follows:
* syscall_exit_work:
- work_pending: // start_of_the_loop
- work_notify_sig:
- do_notify_resume()
- do_signal()
- if (!user_mode(regs)) return;
- resume_userspace // TIF_SIGPENDING is still set
- work_pending // so we call work_pending => goto
// start_of_the_loopMore information can be found in another LKML thread:
http://www.serverphorums.com/read.php?12,457826[1] the problem was also seen on MIPS.
Signed-off-by: Dmitry Adamushko
Link: http://lkml.kernel.org/r/1332448765.2299.68.camel@dimm
Cc: Oleg Nesterov
Cc: Roland McGrath
Cc: Andrew Morton
Signed-off-by: H. Peter Anvin
Signed-off-by: Greg Kroah-Hartman -
commit 13354dc412c36fe554f9904a92f1268c74af7e87 upstream.
Syscall 282 was mistakenly named mq_getsetaddr instead of mq_getsetattr.
When building uClibc against the Linux kernel this would result in a
shared library that doesn't provide the mq_getattr() and mq_setattr()
functions.Signed-off-by: Thierry Reding
Link: http://lkml.kernel.org/r/1332366608-2695-2-git-send-email-thierry.reding@avionic-design.de
Signed-off-by: H. Peter Anvin
Signed-off-by: Greg Kroah-Hartman -
commit 5d5440a835710d09f0ef18da5000541ec98b537a upstream.
URB unlinking is always racing with its completion and tx_complete
may be called before or during running usb_unlink_urb, so tx_complete
must not clear urb->dev since it will be used in unlink path,
otherwise invalid memory accesses or usb device leak may be caused
inside usb_unlink_urb.Cc: Alan Stern
Cc: Oliver Neukum
Signed-off-by: Ming Lei
Acked-by: Greg Kroah-Hartman
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
commit 0956a8c20b23d429e79ff86d4325583fc06f9eb4 upstream.
Commit 4231d47e6fe69f061f96c98c30eaf9fb4c14b96d(net/usbnet: avoid
recursive locking in usbnet_stop()) fixes the recursive locking
problem by releasing the skb queue lock, but it makes usb_unlink_urb
racing with defer_bh, and the URB to being unlinked may be freed before
or during calling usb_unlink_urb, so use-after-free problem may be
triggerd inside usb_unlink_urb.The patch fixes the use-after-free problem by increasing URB
reference count with skb queue lock held before calling
usb_unlink_urb, so the URB won't be freed until return from
usb_unlink_urb.Cc: Sebastian Andrzej Siewior
Cc: Alan Stern
Cc: Oliver Neukum
Reported-by: Dave Jones
Signed-off-by: Ming Lei
Acked-by: Greg Kroah-Hartman
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
commit 540a0f7584169651f485e8ab67461fcb06934e38 upstream.
The problem is that for the case of priority queues, we
have to assume that __rpc_remove_wait_queue_priority will move new
elements from the tk_wait.links lists into the queue->tasks[] list.
We therefore cannot use list_for_each_entry_safe() on queue->tasks[],
since that will skip these new tasks that __rpc_remove_wait_queue_priority
is adding.Without this fix, rpc_wake_up and rpc_wake_up_status will both fail
to wake up all functions on priority wait queues, which can result
in some nasty hangs.Reported-by: Andy Adamson
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman -
commit 7eb3aa65853e1b223bfc786b023b702018cb76c0 upstream.
The 'find_wl_entry()' function expects the maximum difference as the second
argument, not the maximum absolute value. So the "unknown" eraseblock picking
was incorrect, as Shmulik Ladkani spotted. This patch fixes the issue.Reported-by: Shmulik Ladkani
Signed-off-by: Artem Bityutskiy
Reviewed-by: Shmulik Ladkani
Signed-off-by: Greg Kroah-Hartman -
commit a29852be492d61001d86c6ebf5fff9b93d7b4be9 upstream.
Two bad things can happen in ubi_scan():
1. If kmem_cache_create() fails we jump to out_si and call
ubi_scan_destroy_si() which calls kmem_cache_destroy().
But si->scan_leb_slab is NULL.
2. If process_eb() fails we jump to out_vidh, call
kmem_cache_destroy() and ubi_scan_destroy_si() which calls
again kmem_cache_destroy().Signed-off-by: Richard Weinberger
Signed-off-by: Artem Bityutskiy
Signed-off-by: Greg Kroah-Hartman -
commit ce85852b90a214cf577fc1b4f49d99fd7e98784a upstream.
Signed-off-by: Pavel Shilovsky
Reviewed-by: Jeff Layton
Reported-by: Ben Hutchings
Signed-off-by: Steve French
Signed-off-by: Greg Kroah-Hartman -
commit 1daaae8fa4afe3df78ca34e724ed7e8187e4eb32 upstream.
This patch fixes an issue when cifs_mount receives a
STATUS_BAD_NETWORK_NAME error during cifs_get_tcon but is able to
continue after an DFS ROOT referral. In this case, the return code
variable is not reset prior to trying to mount from the system referred
to. Thus, is_path_accessible is not executed and the final DFS referral
is not performed causing a mount error.Use case: In DNS, example.com resolves to the secondary AD server
ad2.example.com Our primary domain controller is ad1.example.com and has
a DFS redirection set up from \\ad1\share\Users to \\files\share\Users.
Mounting \\example.com\share\Users fails.Regression introduced by commit 724d9f1.
Reviewed-by: Pavel Shilovsky
Signed-off-by: Jeff Layton
Signed-off-by: Steve French
Signed-off-by: Greg Kroah-Hartman -
commit 10b9b98e41ba248a899f6175ce96ee91431b6194 upstream.
Some servers sets this value less than 50 that was hardcoded and
we lost the connection if when we exceed this limit. Fix this by
respecting this value - not sending more than the server allows.Reviewed-by: Jeff Layton
Signed-off-by: Pavel Shilovsky
Signed-off-by: Steve French
Signed-off-by: Greg Kroah-Hartman -
commit f30d500f809eca67a21704347ab14bb35877b5ee upstream.
When we get concurrent lookups of the same inode that is not in the
per-AG inode cache, there is a race condition that triggers warnings
in unlock_new_inode() indicating that we are initialising an inode
that isn't in a the correct state for a new inode.When we do an inode lookup via a file handle or a bulkstat, we don't
serialise lookups at a higher level through the dentry cache (i.e.
pathless lookup), and so we can get concurrent lookups of the same
inode.The race condition is between the insertion of the inode into the
cache in the case of a cache miss and a concurrently lookup:Thread 1 Thread 2
xfs_iget()
xfs_iget_cache_miss()
xfs_iread()
lock radix tree
radix_tree_insert()
rcu_read_lock
radix_tree_lookup
lock inode flags
XFS_INEW not set
igrab()
unlock inode flags
rcu_read_unlock
use uninitialised inode
.....
lock inode flags
set XFS_INEW
unlock inode flags
unlock radix tree
xfs_setup_inode()
inode flags = I_NEW
unlock_new_inode()
WARNING as inode flags != I_NEWThis can lead to inode corruption, inode list corruption, etc, and
is generally a bad thing to occur.Fix this by setting XFS_INEW before inserting the inode into the
radix tree. This will ensure any concurrent lookup will find the new
inode with XFS_INEW set and that forces the lookup to wait until the
XFS_INEW flag is removed before allowing the lookup to succeed.Signed-off-by: Dave Chinner
Reviewed-by: Christoph Hellwig
Signed-off-by: Ben Myers
Signed-off-by: Greg Kroah-Hartman -
commit 3114ea7a24d3264c090556a2444fc6d2c06176d4 upstream.
If a setattr() fails because of an NFS4ERR_OPENMODE error, it is
probably due to us holding a read delegation. Ensure that the
recovery routines return that delegation in this case.Reported-by: Miklos Szeredi
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman
