commit e6577f3189d82a729b13e38f3d135f1becd6d294
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Fri Jan 11 09:19:28 2013 -0800
Linux 3.7.2
commit 1dcfb28724803c27657b335dbb8f4494067d10e5
Author: Jeff Layton <jlayton@redhat.com>
Date: Tue Dec 18 06:35:10 2012 -0500
cifs: don't compare uniqueids in cifs_prime_dcache unless server inode numbers are in use
commit 2f2591a34db6c9361faa316c91a6e320cb4e6aee upstream.
Oliver reported that commit cd60042c caused his cifs mounts to
continually thrash through new inodes on readdir. His servers are not
sending inode numbers (or he's not using them), and the new test in
that function doesn't account for that sort of setup correctly.
If we're not using server inode numbers, then assume that the inode
attached to the dentry hasn't changed. Go ahead and update the
attributes in place, but keep the same inode number.
Reported-and-Tested-by: Oliver Mössinger <Oliver.Moessinger@ichaus.de>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 862dc356d36fd84c5673af61364447bd38b453c6
Author: Jeff Layton <jlayton@redhat.com>
Date: Mon Dec 3 06:05:37 2012 -0500
cifs: rename cifs_readdir_lookup to cifs_prime_dcache and make it void return
commit eb1b3fa5cdb9c27bdec8f262acf757a06588eb2d upstream.
The caller doesn't do anything with the dentry, so there's no point in
holding a reference to it on return. Also cifs_prime_dcache better
describes the actual purpose of the function.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <smfrench@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 76e59b0f305a6f2e2ebcfdb8c14750d08ff037ba
Author: Alexander Stein <alexander.stein@systec-electronic.com>
Date: Tue Nov 27 08:52:34 2012 +0100
can: Do not call dev_put if restart timer is running upon close
commit ab48b03ec9ae1840a1e427e2375bd0d9d554b4ed upstream.
If the restart timer is running due to BUS-OFF and the device is
disconnected an dev_put will decrease the usage counter to -1 thus
blocking the interface removal, resulting in the following dmesg
lines repeating every 10s:
can: notifier: receive list not found for dev can0
can: notifier: receive list not found for dev can0
can: notifier: receive list not found for dev can0
unregister_netdevice: waiting for can0 to become free. Usage count = -1
Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 50e54c2c8d010f933b49176b33961e7ad72c0c33
Author: Ben Hutchings <ben@decadent.org.uk>
Date: Sun Dec 2 14:38:23 2012 +0000
HID: Add Apple wireless keyboard 2011 ANSI to special driver list
commit f9af7b9edccb87d4d80b58687ab63e58f3b64c4c upstream.
Commit 0a97e1e9f9a6 ('HID: apple: Add Apple wireless keyboard 2011 ANSI PID')
did not update the special driver list in hid-core.c, so hid-generic may
still bind to this device.
Reported-by: Ari Pollak <ari@scvngr.com>
References: http://bugs.debian.org/694546
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e4ada2b44499ce77e6053679e1f60cad42611b91
Author: Guenter Roeck <linux@roeck-us.net>
Date: Thu Dec 20 15:05:42 2012 -0800
linux/kernel.h: fix DIV_ROUND_CLOSEST with unsigned divisors
commit c4e18497d8fd92eef2c6e7eadcc1a107ccd115ea upstream.
Commit 263a523d18bc ("linux/kernel.h: Fix warning seen with W=1 due to
change in DIV_ROUND_CLOSEST") fixes a warning seen with W=1 due to
change in DIV_ROUND_CLOSEST.
Unfortunately, the C compiler converts divide operations with unsigned
divisors to unsigned, even if the dividend is signed and negative (for
example, -10 / 5U = 858993457). The C standard says "If one operand has
unsigned int type, the other operand is converted to unsigned int", so
the compiler is not to blame. As a result, DIV_ROUND_CLOSEST(0, 2U) and
similar operations now return bad values, since the automatic conversion
of expressions such as "0 - 2U/2" to unsigned was not taken into
account.
Fix by checking for the divisor variable type when deciding which
operation to perform. This fixes DIV_ROUND_CLOSEST(0, 2U), but still
returns bad values for negative dividends divided by unsigned divisors.
Mark the latter case as unsupported.
One observed effect of this problem is that the s2c_hwmon driver reports
a value of 4198403 instead of 0 if the ADC reads 0.
Other impact is unpredictable. Problem is seen if the divisor is an
unsigned variable or constant and the dividend is less than (divisor/2).
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reported-by: Juergen Beisert <jbe@pengutronix.de>
Tested-by: Juergen Beisert <jbe@pengutronix.de>
Cc: Jean Delvare <khali@linux-fr.org>
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@linuxfoundation.org>
commit 787f7301074ccd07a3e82236ca41eefd245f4e07
Author: Michal Hocko <mhocko@suse.cz>
Date: Fri Jan 4 15:35:12 2013 -0800
mm: limit mmu_gather batching to fix soft lockups on !CONFIG_PREEMPT
commit 53a59fc67f97374758e63a9c785891ec62324c81 upstream.
Since commit e303297e6c3a ("mm: extended batches for generic
mmu_gather") we are batching pages to be freed until either
tlb_next_batch cannot allocate a new batch or we are done.
This works just fine most of the time but we can get in troubles with
non-preemptible kernel (CONFIG_PREEMPT_NONE or CONFIG_PREEMPT_VOLUNTARY)
on large machines where too aggressive batching might lead to soft
lockups during process exit path (exit_mmap) because there are no
scheduling points down the free_pages_and_swap_cache path and so the
freeing can take long enough to trigger the soft lockup.
The lockup is harmless except when the system is setup to panic on
softlockup which is not that unusual.
The simplest way to work around this issue is to limit the maximum
number of batches in a single mmu_gather. 10k of collected pages should
be safe to prevent from soft lockups (we would have 2ms for one) even if
they are all freed without an explicit scheduling point.
This patch doesn't add any new explicit scheduling points because it
relies on zap_pmd_range during page tables zapping which calls
cond_resched per PMD.
The following lockup has been reported for 3.0 kernel with a huge
process (in order of hundreds gigs but I do know any more details).
BUG: soft lockup - CPU#56 stuck for 22s! [kernel:31053]
Modules linked in: af_packet nfs lockd fscache auth_rpcgss nfs_acl sunrpc mptctl mptbase autofs4 binfmt_misc dm_round_robin dm_multipath bonding cpufreq_conservative cpufreq_userspace cpufreq_powersave pcc_cpufreq mperf microcode fuse loop osst sg sd_mod crc_t10dif st qla2xxx scsi_transport_fc scsi_tgt netxen_nic i7core_edac iTCO_wdt joydev e1000e serio_raw pcspkr edac_core iTCO_vendor_support acpi_power_meter rtc_cmos hpwdt hpilo button container usbhid hid dm_mirror dm_region_hash dm_log linear uhci_hcd ehci_hcd usbcore usb_common scsi_dh_emc scsi_dh_alua scsi_dh_hp_sw scsi_dh_rdac scsi_dh dm_snapshot pcnet32 mii edd dm_mod raid1 ext3 mbcache jbd fan thermal processor thermal_sys hwmon cciss scsi_mod
Supported: Yes
CPU 56
Pid: 31053, comm: kernel Not tainted 3.0.31-0.9-default #1 HP ProLiant DL580 G7
RIP: 0010: _raw_spin_unlock_irqrestore+0x8/0x10
RSP: 0018:ffff883ec1037af0 EFLAGS: 00000206
RAX: 0000000000000e00 RBX: ffffea01a0817e28 RCX: ffff88803ffd9e80
RDX: 0000000000000200 RSI: 0000000000000206 RDI: 0000000000000206
RBP: 0000000000000002 R08: 0000000000000001 R09: ffff887ec724a400
R10: 0000000000000000 R11: dead000000200200 R12: ffffffff8144c26e
R13: 0000000000000030 R14: 0000000000000297 R15: 000000000000000e
FS: 00007ed834282700(0000) GS:ffff88c03f200000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 000000000068b240 CR3: 0000003ec13c5000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process kernel (pid: 31053, threadinfo ffff883ec1036000, task ffff883ebd5d4100)
Call Trace:
release_pages+0xc5/0x260
free_pages_and_swap_cache+0x9d/0xc0
tlb_flush_mmu+0x5c/0x80
tlb_finish_mmu+0xe/0x50
exit_mmap+0xbd/0x120
mmput+0x49/0x120
exit_mm+0x122/0x160
do_exit+0x17a/0x430
do_group_exit+0x3d/0xb0
get_signal_to_deliver+0x247/0x480
do_signal+0x71/0x1b0
do_notify_resume+0x98/0xb0
int_signal+0x12/0x17
DWARF2 unwinder stuck at int_signal+0x12/0x17
Signed-off-by: Michal Hocko <mhocko@suse.cz>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Rik van Riel <riel@redhat.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
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@linuxfoundation.org>
commit bc2eb9ea9eae3cd2485dad9bb1541f18dffa6c5c
Author: Tony Prisk <linux@prisktech.co.nz>
Date: Fri Jan 4 15:35:48 2013 -0800
drivers/rtc/rtc-vt8500.c: fix handling of data passed in struct rtc_time
commit 2f90b68309683f2c5765a1b04ca23d71e51f1494 upstream.
tm_mon is 0..11, whereas vt8500 expects 1..12 for the month field,
causing invalid date errors for January, and causing the day field to
roll over incorrectly.
The century flag is only handled in vt8500_rtc_read_time, but not set in
vt8500_rtc_set_time. This patch corrects the behaviour of the century
flag.
Signed-off-by: Edgar Toernig <froese@gmx.de>
Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
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@linuxfoundation.org>
commit a28690b32d01b12edb03da62b1180b83fdc5a8b3
Author: Tony Prisk <linux@prisktech.co.nz>
Date: Fri Jan 4 15:35:47 2013 -0800
drivers/rtc/rtc-vt8500.c: correct handling of CR_24H bitfield
commit 532db570e5181abc8f4f7bfa6c77c69ec2240198 upstream.
Control register bitfield for 12H/24H mode is handled incorrectly.
Setting CR_24H actually enables 12H mode. This patch renames the define
and changes the initialization code to correctly set 24H mode.
Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
Cc: Edgar Toernig <froese@gmx.de>
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@linuxfoundation.org>
commit 287376ad9f4cf330c786ac84d9f6a416d9ac0d09
Author: Andrew Morton <akpm@linux-foundation.org>
Date: Thu Dec 20 15:05:34 2012 -0800
revert "rtc: recycle id when unloading a rtc driver"
commit 5abe257af8b95857b95fa0ba694530b446ae32d8 upstream.
Revert commit 2830a6d20139df2198d63235df7957712adb28e5.
We already perform the ida_simple_remove() in rtc_device_release(),
which is an appropriate place. Commit 2830a6d20 ("rtc: recycle id when
unloading a rtc driver") caused the kernel to emit
ida_remove called for id=0 which is not allocated.
warnings when rtc_device_release() tries to release an alread-released
ID.
Let's restore things to their previous state and then work out why
Vincent's kernel wasn't calling rtc_device_release() - presumably a bug
in a specific sub-driver.
Reported-by: Lothar Waßmann <LW@KARO-electronics.de>
Acked-by: Alexander Holler <holler@ahsoftware.de>
Cc: Vincent Palatin <vpalatin@chromium.org>
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@linuxfoundation.org>
commit 423fccba308720afd02ec192c9ca59a167ca3717
Author: Corey Minyard <cminyard@mvista.com>
Date: Tue Dec 18 14:21:19 2012 -0800
CRIS: fix I/O macros
commit c24bf9b4cc6a0f330ea355d73bfdf1dae7e63a05 upstream.
The inb/outb macros for CRIS are broken from a number of points of view,
missing () around parameters and they have an unprotected if statement
in them. This was breaking the compile of IPMI on CRIS and thus I was
being annoyed by build regressions, so I fixed them.
Plus I don't think they would have worked at all, since the data values
were missing "&" and the outsl had a "3" instead of a "4" for the size.
From what I can tell, this stuff is not used at all, so this can't be
any more broken than it was before, anyway.
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Cc: Jesper Nilsson <jesper.nilsson@axis.com>
Cc: Mikael Starvik <starvik@axis.com>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
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@linuxfoundation.org>
commit 3f0f3b1f1d41775078ee2f2a12b148191d5ac8de
Author: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Date: Mon Dec 17 16:03:17 2012 -0800
proc: pid/status: show all supplementary groups
commit 8d238027b87e654be552eabdf492042a34c5c300 upstream.
We display a list of supplementary group for each process in
/proc/<pid>/status. However, we show only the first 32 groups, not all of
them.
Although this is rare, but sometimes processes do have more than 32
supplementary groups, and this kernel limitation breaks user-space apps
that rely on the group list in /proc/<pid>/status.
Number 32 comes from the internal NGROUPS_SMALL macro which defines the
length for the internal kernel "small" groups buffer. There is no
apparent reason to limit to this value.
This patch removes the 32 groups printing limit.
The Linux kernel limits the amount of supplementary groups by NGROUPS_MAX,
which is currently set to 65536. And this is the maximum count of groups
we may possibly print.
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
Acked-by: Kees Cook <keescook@chromium.org>
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@linuxfoundation.org>
commit 65bacde551e409a27dd86dae3801e3726b97ca28
Author: Stephen Boyd <sboyd@codeaurora.org>
Date: Wed Dec 19 23:39:48 2012 -0800
lib: atomic64: Initialize locks statically to fix early users
commit fcc16882ac4532aaa644bff444f0c5d6228ba71e upstream.
The atomic64 library uses a handful of static spin locks to implement
atomic 64-bit operations on architectures without support for atomic
64-bit instructions.
Unfortunately, the spinlocks are initialized in a pure initcall and that
is too late for the vfs namespace code which wants to use atomic64
operations before the initcall is run.
This became a problem as of commit 8823c079ba71: "vfs: Add setns support
for the mount namespace".
This leads to BUG messages such as:
BUG: spinlock bad magic on CPU#0, swapper/0/0
lock: atomic64_lock+0x240/0x400, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
do_raw_spin_lock+0x158/0x198
_raw_spin_lock_irqsave+0x4c/0x58
atomic64_add_return+0x30/0x5c
alloc_mnt_ns.clone.14+0x44/0xac
create_mnt_ns+0xc/0x54
mnt_init+0x120/0x1d4
vfs_caches_init+0xe0/0x10c
start_kernel+0x29c/0x300
coming out early on during boot when spinlock debugging is enabled.
Fix this by initializing the spinlocks statically at compile time.
Reported-and-tested-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
Tested-by: Tony Lindgren <tony@atomide.com>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3d8c1e480a910cf0940f7b375875b567a5a9a771
Author: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Date: Mon Dec 3 15:36:51 2012 -0200
Revert "Bluetooth: Fix possible deadlock in SCO code"
commit 0b27a4b97cb1874503c78453c0903df53c0c86b2 upstream.
This reverts commit 269c4845d5b3627b95b1934107251bacbe99bb68.
The commit was causing dead locks and NULL dereferences in the sco code:
[28084.104013] BUG: soft lockup - CPU#0 stuck for 22s! [kworker/u:0H:7]
[28084.104021] Modules linked in: btusb bluetooth <snip [last unloaded:
bluetooth]
...
[28084.104021] [<c160246d>] _raw_spin_lock+0xd/0x10
[28084.104021] [<f920e708>] sco_conn_del+0x58/0x1b0 [bluetooth]
[28084.104021] [<f920f1a9>] sco_connect_cfm+0xb9/0x2b0 [bluetooth]
[28084.104021] [<f91ef289>]
hci_sync_conn_complete_evt.isra.94+0x1c9/0x260 [bluetooth]
[28084.104021] [<f91f1a8d>] hci_event_packet+0x74d/0x2b40 [bluetooth]
[28084.104021] [<c1501abd>] ? __kfree_skb+0x3d/0x90
[28084.104021] [<c1501b46>] ? kfree_skb+0x36/0x90
[28084.104021] [<f91fcb4e>] ? hci_send_to_monitor+0x10e/0x190 [bluetooth]
[28084.104021] [<f91fcb4e>] ? hci_send_to_monitor+0x10e/0x190 [bluetooth]
Reported-by: Chan-yeol Park <chanyeol.park@gmail.com>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c7cf062d05129d6d75dabfcb96f5c5a4a92d824c
Author: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Date: Wed Nov 21 00:50:21 2012 -0200
Bluetooth: cancel power_on work when unregistering the device
commit b9b5ef188e5a2222cfc16ef62a4703080750b451 upstream.
We need to cancel the hci_power_on work in order to avoid it run when we
try to free the hdev.
[ 1434.201149] ------------[ cut here ]------------
[ 1434.204998] WARNING: at lib/debugobjects.c:261 debug_print_object+0x8e/0xb0()
[ 1434.208324] ODEBUG: free active (active state 0) object type: work_struct hint: hci
_power_on+0x0/0x90
[ 1434.210386] Pid: 8564, comm: trinity-child25 Tainted: G W 3.7.0-rc5-next-
20121112-sasha-00018-g2f4ce0e #127
[ 1434.210760] Call Trace:
[ 1434.210760] [<ffffffff819f3d6e>] ? debug_print_object+0x8e/0xb0
[ 1434.210760] [<ffffffff8110b887>] warn_slowpath_common+0x87/0xb0
[ 1434.210760] [<ffffffff8110b911>] warn_slowpath_fmt+0x41/0x50
[ 1434.210760] [<ffffffff819f3d6e>] debug_print_object+0x8e/0xb0
[ 1434.210760] [<ffffffff8376b750>] ? hci_dev_open+0x310/0x310
[ 1434.210760] [<ffffffff83bf94e5>] ? _raw_spin_unlock_irqrestore+0x55/0xa0
[ 1434.210760] [<ffffffff819f3ee5>] __debug_check_no_obj_freed+0xa5/0x230
[ 1434.210760] [<ffffffff83785db0>] ? bt_host_release+0x10/0x20
[ 1434.210760] [<ffffffff819f4d15>] debug_check_no_obj_freed+0x15/0x20
[ 1434.210760] [<ffffffff8125eee7>] kfree+0x227/0x330
[ 1434.210760] [<ffffffff83785db0>] bt_host_release+0x10/0x20
[ 1434.210760] [<ffffffff81e539e5>] device_release+0x65/0xc0
[ 1434.210760] [<ffffffff819d3975>] kobject_cleanup+0x145/0x190
[ 1434.210760] [<ffffffff819d39cd>] kobject_release+0xd/0x10
[ 1434.210760] [<ffffffff819d33cc>] kobject_put+0x4c/0x60
[ 1434.210760] [<ffffffff81e548b2>] put_device+0x12/0x20
[ 1434.210760] [<ffffffff8376a334>] hci_free_dev+0x24/0x30
[ 1434.210760] [<ffffffff82fd8fe1>] vhci_release+0x31/0x60
[ 1434.210760] [<ffffffff8127be12>] __fput+0x122/0x250
[ 1434.210760] [<ffffffff811cab0d>] ? rcu_user_exit+0x9d/0xd0
[ 1434.210760] [<ffffffff8127bf49>] ____fput+0x9/0x10
[ 1434.210760] [<ffffffff81133402>] task_work_run+0xb2/0xf0
[ 1434.210760] [<ffffffff8106cfa7>] do_notify_resume+0x77/0xa0
[ 1434.210760] [<ffffffff83bfb0ea>] int_signal+0x12/0x17
[ 1434.210760] ---[ end trace a6d57fefbc8a8cc7 ]---
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5795b170bfde23d424fb15d2c945d5dfb827e063
Author: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Date: Tue Nov 20 23:25:54 2012 -0200
Bluetooth: Add missing lock nesting notation
commit dc2a0e20fbc85a71c63aa4330b496fda33f6bf80 upstream.
This patch fixes the following report, it happens when accepting rfcomm
connections:
[ 228.165378] =============================================
[ 228.165378] [ INFO: possible recursive locking detected ]
[ 228.165378] 3.7.0-rc1-00536-gc1d5dc4 #120 Tainted: G W
[ 228.165378] ---------------------------------------------
[ 228.165378] bluetoothd/1341 is trying to acquire lock:
[ 228.165378] (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+...}, at:
[<ffffffffa0000aa0>] bt_accept_dequeue+0xa0/0x180 [bluetooth]
[ 228.165378]
[ 228.165378] but task is already holding lock:
[ 228.165378] (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+...}, at:
[<ffffffffa0205118>] rfcomm_sock_accept+0x58/0x2d0 [rfcomm]
[ 228.165378]
[ 228.165378] other info that might help us debug this:
[ 228.165378] Possible unsafe locking scenario:
[ 228.165378]
[ 228.165378] CPU0
[ 228.165378] ----
[ 228.165378] lock(sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM);
[ 228.165378] lock(sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM);
[ 228.165378]
[ 228.165378] *** DEADLOCK ***
[ 228.165378]
[ 228.165378] May be due to missing lock nesting notation
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2ea3e85ea577adc61acef73b3b83da5ed781da99
Author: Jeff Cook <jeff@deserettechnology.com>
Date: Fri Nov 9 16:39:48 2012 -0700
Bluetooth: Add support for BCM20702A0 [0b05, 17b5]
commit 1ee3ff6110c16acfc915a79b1e3feb5013c41e75 upstream.
Vendor-specific ID for BCM20702A0.
Support for bluetooth over Asus Wi-Fi GO!, included with Asus P8Z77-V
Deluxe.
T: Bus=07 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0b05 ProdID=17b5 Rev=01.12
S: Manufacturer=Broadcom Corp
S: Product=BCM20702A0
S: SerialNumber=94DBC98AC113
C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)
Signed-off-by: Jeff Cook <jeff@deserettechnology.com>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 63be10e5ace81580bd2944aa2f283d75bd2f0a01
Author: Myron Stowe <myron.stowe@redhat.com>
Date: Wed Dec 26 10:39:23 2012 -0700
PCI: Work around Stratus ftServer broken PCIe hierarchy (fix DMI check)
commit 1278998f8ff6d66044ed00b581bbf14aacaba215 upstream.
Commit 284f5f9 was intended to disable the "only_one_child()" optimization
on Stratus ftServer systems, but its DMI check is wrong. It looks for
DMI_SYS_VENDOR that contains "ftServer", when it should look for
DMI_SYS_VENDOR containing "Stratus" and DMI_PRODUCT_NAME containing
"ftServer".
Tested on Stratus ftServer 6400.
Reported-by: Fadeeva Marina <astarta@rat.ru>
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=51331
Signed-off-by: Myron Stowe <myron.stowe@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit dc0e6fecca56cc2ad5c8ce9023e1be6737441cb3
Author: Huang Ying <ying.huang@intel.com>
Date: Wed Dec 26 10:39:23 2012 -0700
PCI/PM: Do not suspend port if any subordinate device needs PME polling
commit c733b77475707cc3980542c86ee0ad5c841d544c upstream.
Ulrich reported that his USB3 cardreader does not work reliably when
connected to the USB3 port. It turns out that USB3 controller failed to
awaken when plugging in the USB3 cardreader. Further experiments found
that the USB3 host controller can only be awakened via polling, not via PME
interrupt. But if the PCIe port to which the USB3 host controller is
connected is suspended, we cannot poll the controller because its config
space is not accessible when the PCIe port is in a low power state.
To solve the issue, the PCIe port will not be suspended if any subordinate
device needs PME polling.
[bhelgaas: use bool consistently rather than mixing int/bool]
Reference: http://lkml.kernel.org/r/50841CCC.9030809@uli-eckhardt.de
Reported-by: Ulrich Eckhardt <usb@uli-eckhardt.de>
Tested-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c9b184487ae4e1ec9c8d11b4ed1a23293fabb2ce
Author: Andy Lutomirski <luto@amacapital.net>
Date: Sat Dec 1 12:37:20 2012 -0800
PCI: Reduce Ricoh 0xe822 SD card reader base clock frequency to 50MHz
commit 812089e01b9f65f90fc8fc670d8cce72a0e01fbb upstream.
Otherwise it fails like this on cards like the Transcend 16GB SDHC card:
mmc0: new SDHC card at address b368
mmcblk0: mmc0:b368 SDC 15.0 GiB
mmcblk0: error -110 sending status command, retrying
mmcblk0: error -84 transferring data, sector 0, nr 8, cmd response 0x900, card status 0xb0
Tested on my Lenovo x200 laptop.
[bhelgaas: changelog]
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Chris Ball <cjb@laptop.org>
CC: Manoj Iyer <manoj.iyer@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0635ca9a8069d8b12debcf0e99cab47a5437997f
Author: Huang Ying <ying.huang@intel.com>
Date: Tue Nov 20 16:08:22 2012 +0800
PCI/PM: Keep runtime PM enabled for unbound PCI devices
commit 967577b062417b4e4b8e27b711220f4124f5153a upstream.
For unbound PCI devices, what we need is:
- Always in D0 state, because some devices do not work again after
being put into D3 by the PCI bus.
- In SUSPENDED state if allowed, so that the parent devices can still
be put into low power state.
To satisfy these requirements, the runtime PM for the unbound PCI
devices are disabled and set to SUSPENDED state. One issue of this
solution is that the PCI devices will be put into SUSPENDED state even
if the SUSPENDED state is forbidden via the sysfs interface
(.../power/control) of the device. This is not an issue for most
devices, because most PCI devices are not used at all if unbound.
But there are exceptions. For example, unbound VGA card can be used
for display, but suspending its parents makes it stop working.
To fix the issue, we keep the runtime PM enabled when the PCI devices
are unbound. But the runtime PM callbacks will do nothing if the PCI
devices are unbound. This way, we can put the PCI devices into
SUSPENDED state without putting the PCI devices into D3 state.
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=48201
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6e9fd9fbb4f2dd2506e708af835e39d00264d8e6
Author: David Woodhouse <dwmw2@infradead.org>
Date: Tue Dec 11 14:57:14 2012 +0000
solos-pci: fix double-free of TX skb in DMA mode
commit cae49ede00ec3d0cda290b03fee55b72b49efc11 upstream.
We weren't clearing card->tx_skb[port] when processing the TX done interrupt.
If there wasn't another skb ready to transmit immediately, this led to a
double-free because we'd free it *again* next time we did have a packet to
send.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 756c3f692b7c5158dfe545fe56c517b6e065688b
Author: Jeff Layton <jlayton@redhat.com>
Date: Thu Dec 27 08:05:03 2012 -0500
cifs: adjust sequence number downward after signing NT_CANCEL request
commit 31efee60f489c759c341454d755a9fd13de8c03d upstream.
When a call goes out, the signing code adjusts the sequence number
upward by two to account for the request and the response. An NT_CANCEL
however doesn't get a response of its own, it just hurries the server
along to get it to respond to the original request more quickly.
Therefore, we must adjust the sequence number back down by one after
signing a NT_CANCEL request.
Reported-by: Tim Perry <tdparmor-sambabugs@yahoo.com>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <smfrench@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7696b6d4dcfbc9fb8bd4c91774424197a4b2cc39
Author: Jeff Layton <jlayton@redhat.com>
Date: Thu Dec 27 07:28:55 2012 -0500
cifs: move check for NULL socket into smb_send_rqst
commit ea702b80e0bbb2448e201472127288beb82ca2fe upstream.
Cai reported this oops:
[90701.616664] BUG: unable to handle kernel NULL pointer dereference at 0000000000000028
[90701.625438] IP: [<ffffffff814a343e>] kernel_setsockopt+0x2e/0x60
[90701.632167] PGD fea319067 PUD 103fda4067 PMD 0
[90701.637255] Oops: 0000 [#1] SMP
[90701.640878] Modules linked in: des_generic md4 nls_utf8 cifs dns_resolver binfmt_misc tun sg igb iTCO_wdt iTCO_vendor_support lpc_ich pcspkr i2c_i801 i2c_core i7core_edac edac_core ioatdma dca mfd_core coretemp kvm_intel kvm crc32c_intel microcode sr_mod cdrom ata_generic sd_mod pata_acpi crc_t10dif ata_piix libata megaraid_sas dm_mirror dm_region_hash dm_log dm_mod
[90701.677655] CPU 10
[90701.679808] Pid: 9627, comm: ls Tainted: G W 3.7.1+ #10 QCI QSSC-S4R/QSSC-S4R
[90701.688950] RIP: 0010:[<ffffffff814a343e>] [<ffffffff814a343e>] kernel_setsockopt+0x2e/0x60
[90701.698383] RSP: 0018:ffff88177b431bb8 EFLAGS: 00010206
[90701.704309] RAX: ffff88177b431fd8 RBX: 00007ffffffff000 RCX: ffff88177b431bec
[90701.712271] RDX: 0000000000000003 RSI: 0000000000000006 RDI: 0000000000000000
[90701.720223] RBP: ffff88177b431bc8 R08: 0000000000000004 R09: 0000000000000000
[90701.728185] R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000001
[90701.736147] R13: ffff88184ef92000 R14: 0000000000000023 R15: ffff88177b431c88
[90701.744109] FS: 00007fd56a1a47c0(0000) GS:ffff88105fc40000(0000) knlGS:0000000000000000
[90701.753137] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[90701.759550] CR2: 0000000000000028 CR3: 000000104f15f000 CR4: 00000000000007e0
[90701.767512] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[90701.775465] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[90701.783428] Process ls (pid: 9627, threadinfo ffff88177b430000, task ffff88185ca4cb60)
[90701.792261] Stack:
[90701.794505] 0000000000000023 ffff88177b431c50 ffff88177b431c38 ffffffffa014fcb1
[90701.802809] ffff88184ef921bc 0000000000000000 00000001ffffffff ffff88184ef921c0
[90701.811123] ffff88177b431c08 ffffffff815ca3d9 ffff88177b431c18 ffff880857758000
[90701.819433] Call Trace:
[90701.822183] [<ffffffffa014fcb1>] smb_send_rqst+0x71/0x1f0 [cifs]
[90701.828991] [<ffffffff815ca3d9>] ? schedule+0x29/0x70
[90701.834736] [<ffffffffa014fe6d>] smb_sendv+0x3d/0x40 [cifs]
[90701.841062] [<ffffffffa014fe96>] smb_send+0x26/0x30 [cifs]
[90701.847291] [<ffffffffa015801f>] send_nt_cancel+0x6f/0xd0 [cifs]
[90701.854102] [<ffffffffa015075e>] SendReceive+0x18e/0x360 [cifs]
[90701.860814] [<ffffffffa0134a78>] CIFSFindFirst+0x1a8/0x3f0 [cifs]
[90701.867724] [<ffffffffa013f731>] ? build_path_from_dentry+0xf1/0x260 [cifs]
[90701.875601] [<ffffffffa013f731>] ? build_path_from_dentry+0xf1/0x260 [cifs]
[90701.883477] [<ffffffffa01578e6>] cifs_query_dir_first+0x26/0x30 [cifs]
[90701.890869] [<ffffffffa015480d>] initiate_cifs_search+0xed/0x250 [cifs]
[90701.898354] [<ffffffff81195970>] ? fillonedir+0x100/0x100
[90701.904486] [<ffffffffa01554cb>] cifs_readdir+0x45b/0x8f0 [cifs]
[90701.911288] [<ffffffff81195970>] ? fillonedir+0x100/0x100
[90701.917410] [<ffffffff81195970>] ? fillonedir+0x100/0x100
[90701.923533] [<ffffffff81195970>] ? fillonedir+0x100/0x100
[90701.929657] [<ffffffff81195848>] vfs_readdir+0xb8/0xe0
[90701.935490] [<ffffffff81195b9f>] sys_getdents+0x8f/0x110
[90701.941521] [<ffffffff815d3b99>] system_call_fastpath+0x16/0x1b
[90701.948222] Code: 66 90 55 65 48 8b 04 25 f0 c6 00 00 48 89 e5 53 48 83 ec 08 83 fe 01 48 8b 98 48 e0 ff ff 48 c7 80 48 e0 ff ff ff ff ff ff 74 22 <48> 8b 47 28 ff 50 68 65 48 8b 14 25 f0 c6 00 00 48 89 9a 48 e0
[90701.970313] RIP [<ffffffff814a343e>] kernel_setsockopt+0x2e/0x60
[90701.977125] RSP <ffff88177b431bb8>
[90701.981018] CR2: 0000000000000028
[90701.984809] ---[ end trace 24bd602971110a43 ]---
This is likely due to a race vs. a reconnection event.
The current code checks for a NULL socket in smb_send_kvec, but that's
too late. By the time that check is done, the socket will already have
been passed to kernel_setsockopt. Move the check into smb_send_rqst, so
that it's checked earlier.
In truth, this is a bit of a half-assed fix. The -ENOTSOCK error
return here looks like it could bubble back up to userspace. The locking
rules around the ssocket pointer are really unclear as well. There are
cases where the ssocket pointer is changed without holding the srv_mutex,
but I'm not clear whether there's a potential race here yet or not.
This code seems like it could benefit from some fundamental re-think of
how the socket handling should behave. Until then though, this patch
should at least fix the above oops in most cases.
Reported-and-Tested-by: CAI Qian <caiqian@redhat.com>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <smfrench@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ff68026c74ea60403004010c4cc1f81b1f4faa2a
Author: Jan Kara <jack@suse.cz>
Date: Wed Dec 5 14:40:14 2012 +0100
fs: Fix imbalance in freeze protection in mark_files_ro()
commit 72651cac884b1e285fa8e8314b10e9f1b8458802 upstream.
File descriptors (even those for writing) do not hold freeze protection.
Thus mark_files_ro() must call __mnt_drop_write() to only drop protection
against remount read-only. Calling mnt_drop_write_file() as we do now
results in:
[ BUG: bad unlock balance detected! ]
3.7.0-rc6-00028-g88e75b6 #101 Not tainted
-------------------------------------
kworker/1:2/79 is trying to release lock (sb_writers) at:
[<ffffffff811b33b4>] mnt_drop_write+0x24/0x30
but there are no more locks to release!
Reported-by: Zdenek Kabelac <zkabelac@redhat.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit bbe614b3f9a1cab9cdd88ecdd9415bd3dd04efd3
Author: Will Deacon <will.deacon@arm.com>
Date: Wed Dec 19 15:01:08 2012 +0100
ARM: 7606/1: cache: flush to LoUU instead of LoUIS on uniprocessor CPUs
commit d056a699dd3d9366dd3b4d9996e7848209199cda upstream.
flush_cache_louis flushes the D-side caches to the point of unification
inner-shareable. On uniprocessor CPUs, this is defined as zero and
therefore no flushing will take place. Rather than invent a new interface
for UP systems, instead use our SMP_ON_UP patching code to read the
LoUU from the CLIDR instead.
Cc: Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>
Tested-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4faefc4ea2f866e9d924f47eacea45a114b8d0d1
Author: Will Deacon <will.deacon@arm.com>
Date: Wed Dec 19 15:01:50 2012 +0100
ARM: 7607/1: realview: fix private peripheral memory base for EB rev. B boards
commit e6ee4b2b57a8e0d8e551031173de080b338d3969 upstream.
Commit 34ae6c96a6a7 ("ARM: 7298/1: realview: fix mapping of MPCore
private memory region") accidentally broke the definition for the base
address of the private peripheral region on revision B Realview-EB
boards.
This patch uses the correct address for REALVIEW_EB11MP_PRIV_MEM_BASE.
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Tested-by: Florian Fainelli <florian@openwrt.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f41983f43cfa6643ff0d1f1c310d4d3eb3412770
Author: Al Viro <viro@ZenIV.linux.org.uk>
Date: Sun Dec 16 00:25:57 2012 +0000
ARM: missing ->mmap_sem around find_vma() in swp_emulate.c
commit 7bf9b7bef881aac820bf1f2e9951a17b09bd7e04 upstream.
find_vma() is *not* safe when somebody else is removing vmas. Not just
the return value might get bogus just as you are getting it (this instance
doesn't try to dereference the resulting vma), the search itself can get
buggered in rather spectacular ways. IOW, ->mmap_sem really, really is
not optional here.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3f6c363d7bf291a026e4c3d2abe1d0767b0468e1
Author: Will Deacon <will.deacon@arm.com>
Date: Tue Sep 18 19:18:35 2012 +0100
ARM: mm: use pteval_t to represent page protection values
commit 864aa04cd02979c2c755cb28b5f4fe56039171c0 upstream.
When updating the page protection map after calculating the user_pgprot
value, the base protection map is temporarily stored in an unsigned long
type, causing truncation of the protection bits when LPAE is enabled.
This effectively means that calls to mprotect() will corrupt the upper
page attributes, clearing the XN bit unconditionally.
This patch uses pteval_t to store the intermediate protection values,
preserving the upper bits for 64-bit descriptors.
Acked-by: Nicolas Pitre <nico@linaro.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7a13eba369913bfd2f363b722d2831db5c3669df
Author: Al Viro <viro@ZenIV.linux.org.uk>
Date: Wed Dec 5 11:48:56 2012 +0000
arm64: compat for clock_adjtime(2) is miswired
commit 18a80376ddb0bdc466995ff58c844d6fd0a65e61 upstream.
struct timex is different on arm and arm64; adjtimex(2) takes care to
convert, clock_adjtime(2) doesn't...
Signed-off-by: Al Viro <viro@ZenIV.linux.org.uk>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f8b723cc9f1a9eec83c8527d67eedc6249b7fb66
Author: Dave Chinner <dchinner@redhat.com>
Date: Wed Nov 28 13:01:02 2012 +1100
xfs: fix stray dquot unlock when reclaiming dquots
commit b870553cdecb26d5291af09602352b763e323df2 upstream.
When we fail to get a dquot lock during reclaim, we jump to an error
handler that unlocks the dquot. This is wrong as we didn't lock the
dquot, and unlocking it means who-ever is holding the lock has had
it silently taken away, and hence it results in a lock imbalance.
Found by inspection while modifying the code for the numa-lru
patchset. This fixes a random hang I've been seeing on xfstest 232
for the past several months.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Ben Myers <bpm@sgi.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 82251473514fde36ce8dc0167f41eaf7ef6a4cb9
Author: Dave Chinner <dchinner@redhat.com>
Date: Wed Nov 28 13:01:00 2012 +1100
xfs: fix direct IO nested transaction deadlock.
commit 437a255aa23766666aec78af63be4c253faa8d57 upstream.
The direct IO path can do a nested transaction reservation when
writing past the EOF. The first transaction is the append
transaction for setting the filesize at IO completion, but we can
also need a transaction for allocation of blocks. If the log is low
on space due to reservations and small log, the append transaction
can be granted after wating for space as the only active transaction
in the system. This then attempts a reservation for an allocation,
which there isn't space in the log for, and the reservation sleeps.
The result is that there is nothing left in the system to wake up
all the processes waiting for log space to come free.
The stack trace that shows this deadlock is relatively innocuous:
xlog_grant_head_wait
xlog_grant_head_check
xfs_log_reserve
xfs_trans_reserve
xfs_iomap_write_direct
__xfs_get_blocks
xfs_get_blocks_direct
do_blockdev_direct_IO
__blockdev_direct_IO
xfs_vm_direct_IO
generic_file_direct_write
xfs_file_dio_aio_writ
xfs_file_aio_write
do_sync_write
vfs_write
This was discovered on a filesystem with a log of only 10MB, and a
log stripe unit of 256k whih increased the base reservations by
512k. Hence a allocation transaction requires 1.2MB of log space to
be available instead of only 260k, and so greatly increased the
chance that there wouldn't be enough log space available for the
nested transaction to succeed. The key to reproducing it is this
mkfs command:
mkfs.xfs -f -d agcount=16,su=256k,sw=12 -l su=256k,size=2560b $SCRATCH_DEV
The test case was a 1000 fsstress processes running with random
freeze and unfreezes every few seconds. Thanks to Eryu Guan
(eguan@redhat.com) for writing the test that found this on a system
with a somewhat unique default configuration....
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Andrew Dahl <adahl@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5a88b8abb0a0f7b4611daaf5305c6cc08cdf5d2b
Author: Oleg Nesterov <oleg@redhat.com>
Date: Sat Jan 5 19:13:13 2013 +0100
signals: sys_ssetmask() uses uninitialized newmask
commit 5ba53ff648e785445a32ba39112ed07e4cf588d0 upstream.
Commit 77097ae503b1 ("most of set_current_blocked() callers want
SIGKILL/SIGSTOP removed from set") removed the initialization of newmask
by accident, causing ltp to complain like this:
ssetmask01 1 TFAIL : sgetmask() failed: TEST_ERRNO=???(0): Success
Restore the proper initialization.
Reported-and-tested-by: CAI Qian <caiqian@redhat.com>
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit bcfab4b51440df476ed319f44c21043ceb317198
Author: Roland Dreier <roland@purestorage.com>
Date: Fri Jan 4 15:35:50 2013 -0800
printk: fix incorrect length from print_time() when seconds > 99999
commit 35dac27cedd14c3b6fcd4ba7bc3c31738cfd1831 upstream.
print_prefix() passes a NULL buf to print_time() to get the length of
the time prefix; when printk times are enabled, the current code just
returns the constant 15, which matches the format "[%5lu.%06lu] " used
to print the time value. However, this is obviously incorrect when the
whole seconds part of the time gets beyond 5 digits (100000 seconds is a
bit more than a day of uptime).
The simple fix is to use snprintf(NULL, 0, ...) to calculate the actual
length of the time prefix. This could be micro-optimized but it seems
better to have simpler, more readable code here.
The bug leads to the syslog system call miscomputing which messages fit
into the userspace buffer. If there are enough messages to fill
log_buf_len and some have a timestamp >= 100000, dmesg may fail with:
# dmesg
klogctl: Bad address
When this happens, strace shows that the failure is indeed EFAULT due to
the kernel mistakenly accessing past the end of dmesg's buffer, since
dmesg asks the kernel how big a buffer it needs, allocates a bit more,
and then gets an error when it asks the kernel to fill it:
syslog(0xa, 0, 0) = 1048576
mmap(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa4d25d2000
syslog(0x3, 0x7fa4d25d2010, 0x100008) = -1 EFAULT (Bad address)
As far as I can see, the bug has been there as long as print_time(),
which comes from commit 084681d14e42 ("printk: flush continuation lines
immediately to console") in 3.5-rc5.
Signed-off-by: Roland Dreier <roland@purestorage.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Joe Perches <joe@perches.com>
Cc: Sylvain Munaut <s.munaut@whatever-company.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@linuxfoundation.org>
commit 191199ac78d4707fbf1e841224d62e2672bd6902
Author: Eric Dumazet <edumazet@google.com>
Date: Sun Jan 6 18:21:49 2013 +0000
tcp: fix MSG_SENDPAGE_NOTLAST logic
[ Upstream commit ae62ca7b03217be5e74759dc6d7698c95df498b3 ]
commit 35f9c09fe9c72e (tcp: tcp_sendpages() should call tcp_push() once)
added an internal flag : MSG_SENDPAGE_NOTLAST meant to be set on all
frags but the last one for a splice() call.
The condition used to set the flag in pipe_to_sendpage() relied on
splice() user passing the exact number of bytes present in the pipe,
or a smaller one.
But some programs pass an arbitrary high value, and the test fails.
The effect of this bug is a lack of tcp_push() at the end of a
splice(pipe -> socket) call, and possibly very slow or erratic TCP
sessions.
We should both test sd->total_len and fact that another fragment
is in the pipe (pipe->nrbufs > 1)
Many thanks to Willy for providing very clear bug report, bisection
and test programs.
Reported-by: Willy Tarreau <w@1wt.eu>
Bisected-by: Willy Tarreau <w@1wt.eu>
Tested-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b5810b8da2248adc73a1bf3def752d99beb87cca
Author: Daniel Borkmann <dborkman@redhat.com>
Date: Sat Dec 15 10:12:43 2012 +0000
sctp: jsctp_sf_eat_sack: fix jprobes function signature mismatch
[ Upstream commit 4cb9d6eaf85ecdd266a9a5c6d825c56ca9eefc14 ]
Commit 24cb81a6a (sctp: Push struct net down into all of the
state machine functions) introduced the net structure into all
state machine functions, but jsctp_sf_eat_sack was not updated,
hence when SCTP association probing is enabled in the kernel,
any simple SCTP client/server program from userspace will panic
the kernel.
Cc: Vlad Yasevich <vyasevich@gmail.com>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 316899aceab5510d296f9437e410401409e9ce19
Author: Stefan Hasko <hasko.stevo@gmail.com>
Date: Fri Dec 21 15:04:59 2012 +0000
net: sched: integer overflow fix
[ Upstream commit d2fe85da52e89b8012ffad010ef352a964725d5f ]
Fixed integer overflow in function htb_dequeue
Signed-off-by: Stefan Hasko <hasko.stevo@gmail.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ae51878d61c4b39eae37d1bf29032e185b8e6501
Author: Alexander Aring <alex.aring@googlemail.com>
Date: Wed Jan 2 01:01:10 2013 +0000
mac802154: fix NOHZ local_softirq_pending 08 warning
[ Upstream commit 5ff3fec6d3fc848753c2fa30b18607358f89a202 ]
When using nanosleep() in an userspace application we get a
ratelimit warning
NOHZ: local_softirq_pending 08
for 10 times.
This patch replaces netif_rx() with netif_rx_ni() which has
to be used from process/softirq context.
The process/softirq context will be called from fakelb driver.
See linux-kernel commit 481a819 for similar fix.
Signed-off-by: Alexander Aring <alex.aring@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 29a21388c86ffa0d18018a7ddf49aa129588a339
Author: Duan Jiong <djduanjiong@gmail.com>
Date: Fri Dec 14 02:59:59 2012 +0000
ipv6: Change skb->data before using icmpv6_notify() to propagate redirect
[ Upstream commit 093d04d42fa094f6740bb188f0ad0c215ff61e2c ]
In function ndisc_redirect_rcv(), the skb->data points to the transport
header, but function icmpv6_notify() need the skb->data points to the
inner IP packet. So before using icmpv6_notify() to propagate redirect,
change skb->data to point the inner IP packet that triggered the sending
of the Redirect, and introduce struct rd_msg to make it easy.
Signed-off-by: Duan Jiong <djduanjiong@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9ce4b845ed059b9104f3bb204db6306e52b25d1b
Author: Christoph Paasch <christoph.paasch@uclouvain.be>
Date: Fri Dec 14 04:07:58 2012 +0000
inet: Fix kmemleak in tcp_v4/6_syn_recv_sock and dccp_v4/6_request_recv_sock
[ Upstream commit e337e24d6624e74a558aa69071e112a65f7b5758 ]
If in either of the above functions inet_csk_route_child_sock() or
__inet_inherit_port() fails, the newsk will not be freed:
unreferenced object 0xffff88022e8a92c0 (size 1592):
comm "softirq", pid 0, jiffies 4294946244 (age 726.160s)
hex dump (first 32 bytes):
0a 01 01 01 0a 01 01 02 00 00 00 00 a7 cc 16 00 ................
02 00 03 01 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff8153d190>] kmemleak_alloc+0x21/0x3e
[<ffffffff810ab3e7>] kmem_cache_alloc+0xb5/0xc5
[<ffffffff8149b65b>] sk_prot_alloc.isra.53+0x2b/0xcd
[<ffffffff8149b784>] sk_clone_lock+0x16/0x21e
[<ffffffff814d711a>] inet_csk_clone_lock+0x10/0x7b
[<ffffffff814ebbc3>] tcp_create_openreq_child+0x21/0x481
[<ffffffff814e8fa5>] tcp_v4_syn_recv_sock+0x3a/0x23b
[<ffffffff814ec5ba>] tcp_check_req+0x29f/0x416
[<ffffffff814e8e10>] tcp_v4_do_rcv+0x161/0x2bc
[<ffffffff814eb917>] tcp_v4_rcv+0x6c9/0x701
[<ffffffff814cea9f>] ip_local_deliver_finish+0x70/0xc4
[<ffffffff814cec20>] ip_local_deliver+0x4e/0x7f
[<ffffffff814ce9f8>] ip_rcv_finish+0x1fc/0x233
[<ffffffff814cee68>] ip_rcv+0x217/0x267
[<ffffffff814a7bbe>] __netif_receive_skb+0x49e/0x553
[<ffffffff814a7cc3>] netif_receive_skb+0x50/0x82
This happens, because sk_clone_lock initializes sk_refcnt to 2, and thus
a single sock_put() is not enough to free the memory. Additionally, things
like xfrm, memcg, cookie_values,... may have been initialized.
We have to free them properly.
This is fixed by forcing a call to tcp_done(), ending up in
inet_csk_destroy_sock, doing the final sock_put(). tcp_done() is necessary,
because it ends up doing all the cleanup on xfrm, memcg, cookie_values,
xfrm,...
Before calling tcp_done, we have to set the socket to SOCK_DEAD, to
force it entering inet_csk_destroy_sock. To avoid the warning in
inet_csk_destroy_sock, inet_num has to be set to 0.
As inet_csk_destroy_sock does a dec on orphan_count, we first have to
increase it.
Calling tcp_done() allows us to remove the calls to
tcp_clear_xmit_timer() and tcp_cleanup_congestion_control().
A similar approach is taken for dccp by calling dccp_done().
This is in the kernel since 093d282321 (tproxy: fix hash locking issue
when using port redirection in __inet_inherit_port()), thus since
version >= 2.6.37.
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6558b40d737d831bad3214a40eac72b226190673
Author: Akinobu Mita <akinobu.mita@gmail.com>
Date: Wed Dec 26 02:32:10 2012 +0000
batman-adv: fix random jitter calculation
[ Upstream commit 143cdd8f33909ff5a153e3f02048738c5964ba26 ]
batadv_iv_ogm_emit_send_time() attempts to calculates a random integer
in the range of 'orig_interval +- BATADV_JITTER' by the below lines.
msecs = atomic_read(&bat_priv->orig_interval) - BATADV_JITTER;
msecs += (random32() % 2 * BATADV_JITTER);
But it actually gets 'orig_interval' or 'orig_interval - BATADV_JITTER'
because '%' and '*' have same precedence and associativity is
left-to-right.
This adds the parentheses at the appropriate position so that it matches
original intension.
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Acked-by: Antonio Quartulli <ordex@autistici.org>
Cc: Marek Lindner <lindner_marek@yahoo.de>
Cc: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Cc: Antonio Quartulli <ordex@autistici.org>
Cc: b.a.t.m.a.n@lists.open-mesh.org
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d7371e1b63cf51b89415381bff47b7312cdcef77
Author: David S. Miller <davem@davemloft.net>
Date: Wed Dec 19 15:44:31 2012 -0800
sparc64: Set CRYPTO_TFM_REQ_MAY_SLEEP consistently in CAMELLIA code.
[ Upstream commit 62ba63dc892cf836ecb9ce4fdb7644d45c95070b ]
We use the FPU and therefore cannot sleep during the crypto
loops.
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7716902f6503082b33b7dc79a09467ed110cc95b
Author: David S. Miller <davem@davemloft.net>
Date: Wed Dec 19 15:43:38 2012 -0800
sparc64: Set CRYPTO_TFM_REQ_MAY_SLEEP consistently in DES code.
[ Upstream commit b3a37947074fa0a488d6c7ede58125b2278ab4e8 ]
We use the FPU and therefore cannot sleep during the crypto
loops.
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a74864cb91b49bc6c54f1358dd07a12135b510f7
Author: David S. Miller <davem@davemloft.net>
Date: Wed Dec 19 15:30:07 2012 -0800
sparc64: Fix ECB looping constructs in AES code.
[ Upstream commit ce6889515d5d481a5bd8ce5913dfed18f08310ea ]
Things works better when you increment the source buffer pointer
properly.
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit fe4ddcf94392f83f27b690f32cdd162ccd0f7eb3
Author: David S. Miller <davem@davemloft.net>
Date: Wed Dec 19 15:22:03 2012 -0800
sparc64: Set CRYPTO_TFM_REQ_MAY_SLEEP consistently in AES code.
[ Upstream commit b35d282ef7345320b594d48d8d70caedfa962a01 ]
We use the FPU and therefore cannot sleep during the crypto
loops.
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6d2446753d8fa56e2dbc7147965a063b37bbdf56
Author: David S. Miller <davem@davemloft.net>
Date: Wed Dec 19 15:20:23 2012 -0800
sparc64: Fix AES ctr mode block size.
[ Upstream commit a8d97cef2168ffe5af1aeed6bf6cdc3ce53f3d0b ]
Like the generic versions, we need to support a block size
of '1' for CTR mode AES.
This was discovered thanks to all of the new test cases added by
Jussi Kivilinna.
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0041cdc62ea0350c4be9b7d7dfb03d89310c8765
Author: David S. Miller <davem@davemloft.net>
Date: Wed Dec 19 15:19:11 2012 -0800
sparc64: Fix unrolled AES 256-bit key loops.
[ Upstream commit 9f28ffc03e93343ac04874fda9edb7affea45165 ]
The basic scheme of the block mode assembler is that we start by
enabling the FPU, loading the key into the floating point registers,
then iterate calling the encrypt/decrypt routine for each block.
For the 256-bit key cases, we run short on registers in the unrolled
loops.
So the {ENCRYPT,DECRYPT}_256_2() macros reload the key registers that
get clobbered.
The unrolled macros, {ENCRYPT,DECRYPT}_256(), are not mindful of this.
So if we have a mix of multi-block and single-block calls, the
single-block unrolled 256-bit encrypt/decrypt can run with some
of the key registers clobbered.
Handle this by always explicitly loading those registers before using
the non-unrolled 256-bit macro.
This was discovered thanks to all of the new test cases added by
Jussi Kivilinna.
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 98a4f4ed3db015aa4755d1f6d39c6a03bc29c5d5
Author: Dave Kleikamp <dave.kleikamp@oracle.com>
Date: Mon Dec 17 11:52:47 2012 -0600
sparc: huge_ptep_set_* functions need to call set_huge_pte_at()
[ Upstream commit 6cb9c3697585c47977c42c5cc1b9fc49247ac530 ]
Modifying the huge pte's requires that all the underlying pte's be
modified.
Version 2: added missing flush_tlb_page()
Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: sparclinux@vger.kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a288c9a403bc7d8b9fb6d97183a691aac793337b
Author: Tejun Heo <tj@kernel.org>
Date: Tue Oct 16 15:03:14 2012 -0700
freezer: add missing mb's to freezer_count() and freezer_should_skip()
commit dd67d32dbc5de299d70cc9e10c6c1e29ffa56b92 upstream.
A task is considered frozen enough between freezer_do_not_count() and
freezer_count() and freezers use freezer_should_skip() to test this
condition. This supposedly works because freezer_count() always calls
try_to_freezer() after clearing %PF_FREEZER_SKIP.
However, there currently is nothing which guarantees that
freezer_count() sees %true freezing() after clearing %PF_FREEZER_SKIP
when freezing is in progress, and vice-versa. A task can escape the
freezing condition in effect by freezer_count() seeing !freezing() and
freezer_should_skip() seeing %PF_FREEZER_SKIP.
This patch adds smp_mb()'s to freezer_count() and
freezer_should_skip() such that either %true freezing() is visible to
freezer_count() or !PF_FREEZER_SKIP is visible to
freezer_should_skip().
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e1593cb019046a8e29442a3376d8b30230e6a15d
Author: Steve French <smfrench@gmail.com>
Date: Tue Dec 4 16:56:37 2012 -0600
SMB3 mounts fail with access denied to some servers
commit 52c0f4ad8ed462d81f1d37f56a74a71dc0c9bf0f upstream.
We were checking incorrectly if signatures were required to be sent,
so were always sending signatures after the initial session establishment.
For SMB3 mounts (vers=3.0) this was a problem because we were putting
SMB2 signatures in SMB3 requests which would cause access denied
on mount (the tree connection would fail).
This might also be worth considering for stable (for 3.7), as the
error message on mount (access denied) is confusing to users and
there is no workaround if the server is configured to only
support smb3.0. I am ok either way.
Signed-off-by: Steve French <smfrench@gmail.com>
Reviewed-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4fc832846b7e2afb0775be4521bcd801c60eba1f
Author: Andy Gross <andy.gross@ti.com>
Date: Tue Oct 16 00:17:40 2012 -0500
staging: drm/omap: Fix include error during make
commit b9ed9f0ecf1b5675c64d069e9b53effe276b6f01 upstream.
Fixed include error for drm_mode.h
Signed-off-by: Andy Gross <andy.gross@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 61001c0a21fef142d5a462db15810afbcd95b416
Author: Jianguo Wu <wujianguo@huawei.com>
Date: Tue Dec 18 14:23:19 2012 -0800
mm/hugetlb: create hugetlb cgroup file in hugetlb_init
commit 7179e7bf4592ac5a7b30257a7df6259ee81e51da upstream.
Build kernel with CONFIG_HUGETLBFS=y,CONFIG_HUGETLB_PAGE=y and
CONFIG_CGROUP_HUGETLB=y, then specify hugepagesz=xx boot option, system
will fail to boot.
This failure is caused by following code path:
setup_hugepagesz
hugetlb_add_hstate
hugetlb_cgroup_file_init
cgroup_add_cftypes
kzalloc <--slab is *not available* yet
For this path, slab is not available yet, so memory allocated will be
failed, and cause WARN_ON() in hugetlb_cgroup_file_init().
So I move hugetlb_cgroup_file_init() into hugetlb_init().
[akpm@linux-foundation.org: tweak coding-style, remove pointless __init on inlined function]
[akpm@linux-foundation.org: fix warning]
Signed-off-by: Jianguo Wu <wujianguo@huawei.com>
Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Acked-by: Michal Hocko <mhocko@suse.cz>
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@linuxfoundation.org>
commit 5778e9e966423d834a01de616f29c6bf834c0d8a
Author: Gao feng <gaofeng@cn.fujitsu.com>
Date: Thu Dec 6 14:38:57 2012 +0800
cgroup_rm_file: don't delete the uncreated files
commit f33fddc2b9573d8359f1007d4bbe5cd587a0c093 upstream.
in cgroup_add_file,when creating files for cgroup,
some of creation may be skipped. So we need to avoid
deleting these uncreated files in cgroup_rm_file,
otherwise the warning msg will be triggered.
"cgroup_addrm_files: failed to remove memory_pressure_enabled, err=-2"
Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
Acked-by: Li Zefan <lizefan@huawei.com>
Signed-off-by: Tejun Heo <tj@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d36994375807d655612b0a3f3967e8039bb41100
Author: Tejun Heo <tj@kernel.org>
Date: Mon Nov 19 08:13:35 2012 -0800
cgroup: remove incorrect dget/dput() pair in cgroup_create_dir()
commit 175431635ec09b1d1bba04979b006b99e8305a83 upstream.
cgroup_create_dir() does weird dancing with dentry refcnt. On
success, it gets and then puts it achieving nothing. On failure, it
puts but there isn't no matching get anywhere leading to the following
oops if cgroup_create_file() fails for whatever reason.
------------[ cut here ]------------
kernel BUG at /work/os/work/fs/dcache.c:552!
invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
Modules linked in:
CPU 2
Pid: 697, comm: mkdir Not tainted 3.7.0-rc4-work+ #3 Bochs Bochs
RIP: 0010:[<ffffffff811d9c0c>] [<ffffffff811d9c0c>] dput+0x1dc/0x1e0
RSP: 0018:ffff88001a3ebef8 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff88000e5b1ef8 RCX: 0000000000000403
RDX: 0000000000000303 RSI: 2000000000000000 RDI: ffff88000e5b1f58
RBP: ffff88001a3ebf18 R08: ffffffff82c76960 R09: 0000000000000001
R10: ffff880015022080 R11: ffd9bed70f48a041 R12: 00000000ffffffea
R13: 0000000000000001 R14: ffff88000e5b1f58 R15: 00007fff57656d60
FS: 00007ff05fcb3800(0000) GS:ffff88001fd00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000004046f0 CR3: 000000001315f000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process mkdir (pid: 697, threadinfo ffff88001a3ea000, task ffff880015022080)
Stack:
ffff88001a3ebf48 00000000ffffffea 0000000000000001 0000000000000000
ffff88001a3ebf38 ffffffff811cc889 0000000000000001 ffff88000e5b1ef8
ffff88001a3ebf68 ffffffff811d1fc9 ffff8800198d7f18 ffff880019106ef8
Call Trace:
[<ffffffff811cc889>] done_path_create+0x19/0x50
[<ffffffff811d1fc9>] sys_mkdirat+0x59/0x80
[<ffffffff811d2009>] sys_mkdir+0x19/0x20
[<ffffffff81be1e02>] system_call_fastpath+0x16/0x1b
Code: 00 48 8d 90 18 01 00 00 48 89 93 c0 00 00 00 4c 89 a0 18 01 00 00 48 8b 83 a0 00 00 00 83 80 28 01 00 00 01 e8 e6 6f a0 00 eb 92 <0f> 0b 66 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 49 89 fe 41
RIP [<ffffffff811d9c0c>] dput+0x1dc/0x1e0
RSP <ffff88001a3ebef8>
---[ end trace 1277bcfd9561ddb0 ]---
Fix it by dropping the unnecessary dget/dput() pair.
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Li Zefan <lizefan@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 838a4f8bb1a039ee4ea6de544624d8fd620bf455
Author: Tejun Heo <tj@kernel.org>
Date: Tue Oct 16 15:03:14 2012 -0700
cgroup: cgroup_subsys->fork() should be called after the task is added to css_set
commit 5edee61edeaaebafe584f8fb7074c1ef4658596b upstream.
cgroup core has a bug which violates a basic rule about event
notifications - when a new entity needs to be added, you add that to
the notification list first and then make the new entity conform to
the current state. If done in the reverse order, an event happening
inbetween will be lost.
cgroup_subsys->fork() is invoked way before the new task is added to
the css_set. Currently, cgroup_freezer is the only user of ->fork()
and uses it to make new tasks conform to the current state of the
freezer. If FROZEN state is requested while fork is in progress
between cgroup_fork_callbacks() and cgroup_post_fork(), the child
could escape freezing - the cgroup isn't frozen when ->fork() is
called and the freezer couldn't see the new task on the css_set.
This patch moves cgroup_subsys->fork() invocation to
cgroup_post_fork() after the new task is added to the css_set.
cgroup_fork_callbacks() is removed.
Because now a task may be migrated during cgroup_subsys->fork(),
freezer_fork() is updated so that it adheres to the usual RCU locking
and the rather pointless comment on why locking can be different there
is removed (if it doesn't make anything simpler, why even bother?).
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 27f0a83c49a639749f9e26c5af4b70164922f304
Author: Russell Webb <russell.webb@linux.intel.com>
Date: Fri Nov 9 13:58:49 2012 -0800
xhci: Add Lynx Point LP to list of Intel switchable hosts
commit bb1e5dd7113d2fd178d3af9aca8f480ae0468edf upstream.
Like Lynx Point, Lynx Point LP is also switchable. See
1c12443ab8eba71a658fae4572147e56d1f84f66 for more details.
This patch should be backported to stable kernels as old as 3.0,
that contain commit 69e848c2090aebba5698a1620604c7dccb448684
"Intel xhci: Support EHCI/xHCI port switching."
Signed-off-by: Russell Webb <russell.webb@linux.intel.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 702b2581032ced74efff3f908a3c3133947198fc
Author: Alexis R. Cortes <alexis.cortes@ti.com>
Date: Thu Nov 8 16:59:27 2012 -0600
usb: host: xhci: Stricter conditional for Z1 system models for Compliance Mode Patch
commit b0e4e606ff6ff26da0f60826e75577b56ba4e463 upstream.
This minor patch creates a more stricter conditional for the Z1 sytems for applying
the Compliance Mode Patch, this to avoid the quirk to be applied to models that
contain a "Z1" in their dmi product string but are different from Z1 systems.
This patch should be backported to stable kernels as old as 3.2, that
contain the commit 71c731a296f1b08a3724bd1b514b64f1bda87a23 "usb: host:
xhci: Fix Compliance Mode on SN65LVPE502CP Hardware"
Signed-off-by: Alexis R. Cortes <alexis.cortes@ti.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d0abdff42cb550ae036f9ac3aa168ea7c867f464
Author: Alan Stern <stern@rowland.harvard.edu>
Date: Wed Nov 7 10:31:30 2012 -0500
USB: fix endpoint-disabling for failed config changes
commit 36caff5d795429c572443894e8789c2150dd796b upstream.
This patch (as1631) fixes a bug that shows up when a config change
fails for a device under an xHCI controller. The controller needs to
be told to disable the endpoints that have been enabled for the new
config. The existing code does this, but before storing the
information about which endpoints were enabled! As a result, any
second attempt to install the new config is doomed to fail because
xhci-hcd will refuse to enable an endpoint that is already enabled.
The patch optimistically initializes the new endpoints' device
structures before asking the device to switch to the new config. If
the request fails then the endpoint information is already stored, so
we can use usb_hcd_alloc_bandwidth() to disable the endpoints with no
trouble. The rest of the error path is slightly more complex now; we
have to disable the new interfaces and call put_device() rather than
simply deallocating them.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-and-tested-by: Matthias Schniedermeyer <ms@citd.de>
CC: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3f853877eee9cf53adcce9a52b25db56ff763941
Author: Julius Werner <jwerner@chromium.org>
Date: Thu Nov 1 12:47:59 2012 -0700
xhci: fix null-pointer dereference when destroying half-built segment rings
commit 68e5254adb88bede68285f11fb442a4d34fb550c upstream.
xhci_alloc_segments_for_ring() builds a list of xhci_segments and links
the tail to head at the end (forming a ring). When it bails out for OOM
reasons half-way through, it tries to destroy its half-built list with
xhci_free_segments_for_ring(), even though it is not a ring yet. This
causes a null-pointer dereference upon hitting the last element.
Furthermore, one of its callers (xhci_ring_alloc()) mistakenly believes
the output parameters to be valid upon this kind of OOM failure, and
calls xhci_ring_free() on them. Since the (incomplete) list/ring should
already be destroyed in that case, this would lead to a use after free.
This patch fixes those issues by having xhci_alloc_segments_for_ring()
destroy its half-built, non-circular list manually and destroying the
invalid struct xhci_ring in xhci_ring_alloc() with a plain kfree().
This patch should be backported to kernels as old as 2.6.31, that
contains the commit 0ebbab37422315a5d0cb29792271085bafdf38c0 "USB: xhci:
Ring allocation and initialization."
A separate patch will need to be developed for kernels older than 3.4,
since the ring allocation code was refactored in that kernel.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 056f8bdd03a4a9e3237295696909cee11a3bb651
Author: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Date: Thu Oct 25 15:56:40 2012 -0700
xHCI: Fix TD Size calculation on 1.0 hosts.
commit 4525c0a10dff7ad3669763c28016c7daffc3900e upstream.
The xHCI 1.0 specification made a change to the TD Size field in TRBs.
The value is now the number of packets that remain to be sent in the TD,
not including this TRB. The TD Size value for the last TRB in a TD must
always be zero.
The xHCI function xhci_v1_0_td_remainder() attempts to calculate this,
but it gets it wrong. First, it erroneously reuses the old
xhci_td_remainder function, which will right shift the value by 10. The
xHCI 1.0 spec as of June 2011 says nothing about right shifting by 10.
Second, it does not set the TD size for the last TRB in a TD to zero.
Third, it uses roundup instead of DIV_ROUND_UP. The total packet count
is supposed to be the total number of bytes in this TD, divided by the
max packet size, rounded up. DIV_ROUND_UP is the right function to use
in that case.
With the old code, a TD on an endpoint with max packet size 1024 would
be set up like so:
TRB 1, TRB length = 600 bytes, TD size = 0
TRB 1, TRB length = 200 bytes, TD size = 0
TRB 1, TRB length = 100 bytes, TD size = 0
With the new code, the TD would be set up like this:
TRB 1, TRB length = 600 bytes, TD size = 1
TRB 1, TRB length = 200 bytes, TD size = 1
TRB 1, TRB length = 100 bytes, TD size = 0
This commit should be backported to kernels as old as 3.0, that contain
the commit 4da6e6f247a2601ab9f1e63424e4d944ed4124f3 "xhci 1.0: Update TD
size field format."
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Chintan Mehta <chintan.mehta@sibridgetech.com>
Reported-by: Shimmer Huang <shimmering.h@gmail.com>
Tested-by: Bhavik Kothari <bhavik.kothari@sibridgetech.com>
Tested-by: Shimmer Huang <shimmering.h@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3f605c4b4424a7042bd3ba656af10e3a405d5663
Author: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Date: Thu Oct 25 13:44:12 2012 -0700
xhci: Fix conditional check in bandwidth calculation.
commit 392a07ae3316f2b90b39ce41e66d6f6b5c95de90 upstream.
David reports that at drivers/usb/host/xhci.c:2257:
static bool xhci_is_sync_in_ep(unsigned int ep_type)
{
return (ep_type == ISOC_IN_EP || ep_type != INT_IN_EP);
}
The static analyser cppcheck says
[linux-3.7-rc2/drivers/usb/host/xhci.c:2257]: (style) Redundant condition: If ep_type == 5, the comparison ep_type != 7 is always true.
Maybe the original programmer intention was something like
static bool xhci_is_sync_in_ep(unsigned int ep_type)
{
return (ep_type == ISOC_IN_EP || ep_type == INT_IN_EP);
}
Fix this.
This patch should be backported to stable kernels as old as 3.2, that
contain the commit 2b69899934c63b7b9432568584fb4c4a2924f40c "xhci: USB
3.0 BW checking."
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: David Binderman <dcb314@hotmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2a90b6baab1021ebbd7fdbb4b894ea315650d360
Author: Afzal Mohammed <afzal@ti.com>
Date: Tue Nov 6 20:47:24 2012 +0530
Revert "usb: musb: dsps: remove explicit NOP device creation"
commit d75542263a0b005876d112bbf9ffb23180cc3149 upstream.
This reverts commit d8c3ef256f88b7c6ecd673d03073b5645be9c5e4.
Above mentioned change was made along with multi usb phy change and
adding DT support for nop transceiver. But other two changes did not
make it to mainline. This in effect makes dsps musb wrapper unusable
even for single instance.
Hence revert it so that at least single instance can be supported.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d18d223714855658c62d17fdd8721bb00ad3cd69
Author: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Date: Mon Nov 5 22:26:40 2012 +0300
usb: musb: cppi_dma: export cppi_interrupt()
commit 8b416b0b25d5d8ddb3a91c1d20e1373582c50405 upstream.
Now that DaVinci glue layer can be modular, we must export cppi_interrupt()
that it may call...
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit fc34a7d5ad5dc9df67bbc9969824fb0949dcceb0
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Sat Nov 3 11:52:09 2012 +0100
genirq: Always force thread affinity
commit 04aa530ec04f61875b99c12721162e2964e3318c upstream.
Sankara reported that the genirq core code fails to adjust the
affinity of an interrupt thread in several cases:
1) On request/setup_irq() the call to setup_affinity() happens before
the new action is registered, so the new thread is not notified.
2) For secondary shared interrupts nothing notifies the new thread to
change its affinity.
3) Interrupts which have the IRQ_NO_BALANCE flag set are not moving
the thread either.
Fix this by setting the thread affinity flag right on thread creation
time. This ensures that under all circumstances the thread moves to
the right place. Requires a check in irq_thread_check_affinity for an
existing affinity mask (CONFIG_CPU_MASK_OFFSTACK=y)
Reported-and-tested-by: Sankara Muthukrishnan <sankara.m@gmail.com>
Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1209041738200.2754@ionos
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit dfcffbb7f048e69812ad92a293ea71a6514e4077
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date: Mon Dec 24 09:32:46 2012 -0800
Input: gpio_keys - defer probing if GPIO probing is deferred
commit e324ce61ef483dd26d03502d35666ad48a2e1b33 upstream.
If of_get_gpio_flags() returns an error (as in case when GPIO probe is
deferred) the driver would attempt to claim invalid GPIO. It should
propagate the error code up the stack instead so that the probe either
fails or will be retried later (in case of -EPROBE_DEFER).
Reported-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d9f5f4bc9a6ca2558588eee434027b0b2af2f121
Author: Gabor Juhos <juhosg@openwrt.org>
Date: Sun Dec 23 01:54:58 2012 -0800
Input: gpio_keys_polled - defer probing if GPIO probing is deferred
commit d46329a708c1a3301e272a029266b69339c0877f upstream.
If GPIO probing is deferred, the driver tries to claim an invalid GPIO line
which leads to an error message like this:
gpio-keys-polled buttons.2: unable to claim gpio 4294966779, err=-22
gpio-keys-polled: probe of buttons.2 failed with error -22
We should make sure that error code returned by of_get_gpio_flags (including
-EPROBE_DEFER) is propagated up the stack.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 459825b716b4f7f71d3d0a0da9c7e4192eb371c6
Author: Christophe TORDEUX <christophe@tordeux.net>
Date: Mon Dec 24 09:20:40 2012 -0800
Input: sentelic - only report position of first finger as ST coordinates
commit a25461659050b913e114d282bf58823682eb56b6 upstream.
Report only the position of the first finger as absolute non-MT coordinates,
instead of reporting both fingers alternatively. Actual MT events are
unaffected.
This fixes horizontal and improves vertical scrolling with the touchpad.
Signed-off-by: Christophe TORDEUX <christophe@tordeux.net>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2bf3364673ef36af85003ead8247313f78df515a
Author: Diego Calleja <diegocg@gmail.com>
Date: Mon Dec 3 21:16:11 2012 -0800
Input: wacom - fix touch support for Bamboo Fun CTH-461
commit e12b3cecf221644ccab64d7c30a6df58b7630cb0 upstream.
Commit f393ee2b814e3291c12565000210b3cf10aa5c1d forgot to add the
touch_max property for Wacom Bamboo Fun CTH-461/S, ID 056a:00d2.
This broke the touch functionality for that device. This patch,
(done with help of Ping Cheng), adds the correct value and makes
touch work again.
Signed-off-by: Diego Calleja <diegocg@gmail.com>
Reviewed-by: Ping Cheng <pinglinux@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit df433c41eb955760b92949c2d7a229ace30789db
Author: Peter Popovec <popovec@oko.fei.tuke.sk>
Date: Fri Dec 14 22:57:25 2012 -0800
Input: walkera0701 - fix crash on startup
commit a455e2985f57e2a71566bb8850094af38b2c932d upstream.
The driver's timer must be set up before enabling IRQ handler, otherwise
bad things may happen.
Reported-and-tested-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Peter Popovec <popovec@fei.tuke.sk>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit dfde3c6d130f2e679024bd7b8692a4d00bac4ef8
Author: NeilBrown <neilb@suse.de>
Date: Thu Nov 8 16:09:37 2012 -0800
vfs: d_obtain_alias() needs to use "/" as default name.
commit b911a6bdeef5848c468597d040e3407e0aee04ce upstream.
NFS appears to use d_obtain_alias() to create the root dentry rather than
d_make_root. This can cause 'prepend_path()' to complain that the root
has a weird name if an NFS filesystem is lazily unmounted. e.g. if
"/mnt" is an NFS mount then
{ cd /mnt; umount -l /mnt ; ls -l /proc/self/cwd; }
will cause a WARN message like
WARNING: at /home/git/linux/fs/dcache.c:2624 prepend_path+0x1d7/0x1e0()
...
Root dentry has weird name <>
to appear in kernel logs.
So change d_obtain_alias() to use "/" rather than "" as the anonymous
name.
Signed-off-by: NeilBrown <neilb@suse.de>
Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2fc2d6907a79876e6c9dc3d3cd4565b319756750
Author: Nickolai Zeldovich <nickolai@csail.mit.edu>
Date: Sat Jan 5 14:19:51 2013 -0500
nfs: avoid dereferencing null pointer in initiate_bulk_draining
commit ecf0eb9edbb607d74f74b73c14af8b43f3729528 upstream.
Fix an inverted null pointer check in initiate_bulk_draining().
Signed-off-by: Nickolai Zeldovich <nickolai@csail.mit.edu>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 25191192f7f136dbad081a19cd72521789268f2a
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date: Fri Jan 4 12:47:04 2013 -0500
NFS: Ensure that we free the rpc_task after read and write cleanups are done
commit 6db6dd7d3fd8f7c765dabc376493d6791ab28bd6 upstream.
This patch ensures that we free the rpc_task after the cleanup callbacks
are done in order to avoid a deadlock problem that can be triggered if
the callback needs to wait for another workqueue item to complete.
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: Weston Andros Adamson <dros@netapp.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Bruce Fields <bfields@fieldses.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit bb3330c18aa9340c600706e60de7d8fdf5260420
Author: Xi Wang <xi.wang@gmail.com>
Date: Fri Jan 4 03:22:57 2013 -0500
nfs: fix null checking in nfs_get_option_str()
commit e25fbe380c4e3c09afa98bcdcd9d3921443adab8 upstream.
The following null pointer check is broken.
*option = match_strdup(args);
return !option;
The pointer `option' must be non-null, and thus `!option' is always false.
Use `!*option' instead.
The bug was introduced in commit c5cb09b6f8 ("Cleanup: Factor out some
cut-and-paste code.").
Signed-off-by: Xi Wang <xi.wang@gmail.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0b7d74eb80d06be3b5792cbdd2c77d1ccb05cc4b
Author: Yanchuan Nian <ycnian@gmail.com>
Date: Fri Jan 4 20:19:49 2013 +0800
pnfs: Increase the refcount when LAYOUTGET fails the first time
commit 39e88fcfb1d5c6c4b1ff76ca2ab76cf449b850e8 upstream.
The layout will be set unusable if LAYOUTGET fails. Is it reasonable to
increase the refcount iff LAYOUTGET fails the first time?
Signed-off-by: Yanchuan Nian <ycnian@gmail.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5865afd9e73a8981f38344ddcb42d9f2049c1469
Author: Weston Andros Adamson <dros@netapp.com>
Date: Thu Jan 3 16:42:29 2013 -0500
NFS: Fix access to suid/sgid executables
commit f8d9a897d4384b77f13781ea813156568f68b83e upstream.
nfs_open_permission_mask() should only check MAY_EXEC for files that
are opened with __FMODE_EXEC.
Also fix NFSv4 access-in-open path in a similar way -- openflags must be
used because fmode will not always have FMODE_EXEC set.
This patch fixes https://bugzilla.kernel.org/show_bug.cgi?id=49101
Signed-off-by: Weston Andros Adamson <dros@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e13ddf6bbcfe7ea1f83b9a7a9f698ef461cdff82
Author: Neil Brown <neilb@suse.de>
Date: Fri Dec 7 15:40:55 2012 -0500
nfsd: avoid permission checks on EXCLUSIVE_CREATE replay
commit 7007c90fb9fef593b4aeaeee57e6a6754276c97c upstream.
With NFSv4, if we create a file then open it we explicit avoid checking
the permissions on the file during the open because the fact that we
created it ensures we should be allow to open it (the create and the
open should appear to be a single operation).
However if the reply to an EXCLUSIVE create gets lots and the client
resends the create, the current code will perform the permission check -
because it doesn't realise that it did the open already..
This patch should fix this.
Note that I haven't actually seen this cause a problem. I was just
looking at the code trying to figure out a different EXCLUSIVE open
related issue, and this looked wrong.
(Fix confirmed with pynfs 4.0 test OPEN4--bfields)
Signed-off-by: NeilBrown <neilb@suse.de>
[bfields: use OWNER_OVERRIDE and update for 4.1]
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e5926fdb4ef0eac63dee54009a74878e53777716
Author: J. Bruce Fields <bfields@redhat.com>
Date: Tue Dec 4 18:25:10 2012 -0500
nfsd4: fix oops on unusual readlike compound
commit d5f50b0c290431c65377c4afa1c764e2c3fe5305 upstream.
If the argument and reply together exceed the maximum payload size, then
a reply with a read-like operation can overlow the rq_pages array.
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9dbe75d2b4111884596c498ca0acbaf71952ae97
Author: J. Bruce Fields <bfields@redhat.com>
Date: Fri Nov 16 15:22:43 2012 -0500
nfsd: fix v4 reply caching
commit 57d276d71aef7d8305ff002a070cb98deb2edced upstream.
Very embarassing: 1091006c5eb15cba56785bd5b498a8d0b9546903 "nfsd: turn
on reply cache for NFSv4" missed a line, effectively leaving the reply
cache off in the v4 case. I thought I'd tested that, but I guess not.
This time, wrote a pynfs test to confirm it works.
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7063a3eea85cf9246cdc917096d25d96f1cc341a
Author: Yanchuan Nian <ycnian@gmail.com>
Date: Wed Oct 24 14:44:19 2012 +0800
nfs: fix wrong object type in lockowner_slab
commit 3c40794b2dd0f355ef4e6bf8d85af5dcd7da7ece upstream.
The object type in the cache of lockowner_slab is wrong, and it is
better to fix it.
Signed-off-by: Yanchuan Nian <ycnian@gmail.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4cc423d6e6a6f0003c8e757d47aacec58e729f21
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date: Sat Dec 15 17:12:14 2012 -0500
NFS: Don't use SetPageError in the NFS writeback code
commit ada8e20d044c0fa5610e504ce6fb4578ebd3edd9 upstream.
The writeback code is already capable of passing errors back to user space
by means of the open_context->error. In the case of ENOSPC, Neil Brown
is reporting seeing 2 errors being returned.
Neil writes:
"e.g. if /mnt2/ if an nfs mounted filesystem that has no space then
strace dd if=/dev/zero conv=fsync >> /mnt2/afile count=1
reported Input/output error and the relevant parts of the strace output are:
write(1, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512
fsync(1) = -1 EIO (Input/output error)
close(1) = -1 ENOSPC (No space left on device)"
Neil then shows that the duplication of error messages appears to be due to
the use of the PageError() mechanism, which causes filemap_fdatawait_range
to return the extra EIO. The regression was introduced by
commit 7b281ee026552f10862b617a2a51acf49c829554 (NFS: fsync() must exit
with an error if page writeback failed).
Fix this by removing the call to SetPageError(), and just relying on
open_context->error reporting the ENOSPC back to fsync().
Reported-by: Neil Brown <neilb@suse.de>
Tested-by: Neil Brown <neilb@suse.de>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit fe32340b7fc58c8323eca13e111367be75d61918
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date: Fri Dec 14 16:38:46 2012 -0500
NFS: Fix calls to drop_nlink()
commit 1f018458b30b0d5c535c94e577aa0acbb92e1395 upstream.
It is almost always wrong for NFS to call drop_nlink() after removing a
file. What we really want is to mark the inode's attributes for
revalidation, and we want to ensure that the VFS drops it if we're
reasonably sure that this is the final unlink().
Do the former using the usual cache validity flags, and the latter
by testing if inode->i_nlink == 1, and clearing it in that case.
This also fixes the following warning reported by Neil Brown and
Jeff Layton (among others).
[634155.004438] WARNING:
at /home/abuild/rpmbuild/BUILD/kernel-desktop-3.5.0/lin [634155.004442]
Hardware name: Latitude E6510 [634155.004577] crc_itu_t crc32c_intel
snd_hwdep snd_pcm snd_timer snd soundcor [634155.004609] Pid: 13402, comm:
bash Tainted: G W 3.5.0-36-desktop # [634155.004611] Call Trace:
[634155.004630] [<ffffffff8100444a>] dump_trace+0xaa/0x2b0
[634155.004641] [<ffffffff815a23dc>] dump_stack+0x69/0x6f
[634155.004653] [<ffffffff81041a0b>] warn_slowpath_common+0x7b/0xc0
[634155.004662] [<ffffffff811832e4>] drop_nlink+0x34/0x40
[634155.004687] [<ffffffffa05bb6c3>] nfs_dentry_iput+0x33/0x70 [nfs]
[634155.004714] [<ffffffff8118049e>] dput+0x12e/0x230
[634155.004726] [<ffffffff8116b230>] __fput+0x170/0x230
[634155.004735] [<ffffffff81167c0f>] filp_close+0x5f/0x90
[634155.004743] [<ffffffff81167cd7>] sys_close+0x97/0x100
[634155.004754] [<ffffffff815c3b39>] system_call_fastpath+0x16/0x1b
[634155.004767] [<00007f2a73a0d110>] 0x7f2a73a0d10f
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 22ad97385fd0d4d7d28f54c6a504203e5f498c9e
Author: NeilBrown <neilb@suse.de>
Date: Thu Dec 13 15:14:36 2012 +1100
NFS: avoid NULL dereference in nfs_destroy_server
commit f259613a1e4b44a0cf85a5dafd931be96ee7c9e5 upstream.
In rare circumstances, nfs_clone_server() of a v2 or v3 server can get
an error between setting server->destory (to nfs_destroy_server), and
calling nfs_start_lockd (which will set server->nlm_host).
If this happens, nfs_clone_server will call nfs_free_server which
will call nfs_destroy_server and thence nlmclnt_done(NULL). This
causes the NULL to be dereferenced.
So add a guard to only call nlmclnt_done() if ->nlm_host is not NULL.
The other guards there are irrelevant as nlm_host can only be non-NULL
if one of these flags are set - so remove those tests. (Thanks to Trond
for this suggestion).
This is suitable for any stable kernel since 2.6.25.
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9883793305d5fbcf79c565f3572ba44d2493f8f5
Author: Jeff Layton <jlayton@redhat.com>
Date: Wed Dec 12 11:38:44 2012 -0500
nfs: don't zero out the rest of the page if we hit the EOF on a DIO READ
commit 67fad106a219e083c91c79695bd1807dde1bf7b9 upstream.
Eryu provided a test program that would segfault when attempting to read
past the EOF on file that was opened O_DIRECT. The buffer given to the
read() call was on the stack, and when he attempted to read past it it
would scribble over the rest of the stack page.
If we hit the end of the file on a DIO READ request, then we don't want
to zero out the rest of the buffer. These aren't pagecache pages after
all, and there's no guarantee that the buffers that were passed in
represent entire pages.
Reported-by: Eryu Guan <eguan@redhat.com>
Cc: Fred Isaman <iisaman@netapp.com>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 43d1640924a2bd61e5f8ad156930353bd410e36d
Author: Sven Wegener <sven.wegener@stealer.net>
Date: Sat Dec 8 15:30:18 2012 +0100
NFSv4: Check for buffer length in __nfs4_get_acl_uncached
commit 7d3e91a89b7adbc2831334def9e494dd9892f9af upstream.
Commit 1f1ea6c "NFSv4: Fix buffer overflow checking in
__nfs4_get_acl_uncached" accidently dropped the checking for too small
result buffer length.
If someone uses getxattr on "system.nfs4_acl" on an NFSv4 mount
supporting ACLs, the ACL has not been cached and the buffer suplied is
too short, we still copy the complete ACL, resulting in kernel and user
space memory corruption.
Signed-off-by: Sven Wegener <sven.wegener@stealer.net>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 62ec24f42255d4c140a77f206068b76262c01c53
Author: Jeff Layton <jlayton@redhat.com>
Date: Mon Dec 10 09:25:48 2012 -0500
nfs: don't extend writes to cover entire page if pagecache is invalid
commit 81d9bce5309288086b58b4d97a644e495fef75f2 upstream.
Jian reported that the following sequence would leave "testfile" with
corrupt data:
# mount localhost:/export /mnt/nfs/ -o vers=3
# echo abc > /mnt/nfs/testfile; echo def >> /export/testfile; echo ghi >> /mnt/nfs/testfile
# cat -v /export/testfile
abc
^@^@^@^@ghi
While there's no locking involved here, the operations are serialized,
so CTO should prevent corruption.
The first write to the file is fine and writes 4 bytes. The file is then
extended on the server. When it's reopened a GETATTR is issued and the
size change is noticed. This causes NFS_INO_INVALID_DATA to be set on
the file. Because the file is opened for write only,
nfs_want_read_modify_write() returns 0 to nfs_write_begin().
nfs_updatepage then calls nfs_write_pageuptodate() to see if it should
extend the nfs_page to cover the whole page. NFS_INO_INVALID_DATA is
still set on the file at that point, but that flag is ignored and
nfs_pageuptodate erroneously extends the write to cover the whole page,
with the write done on the server side filled in with zeroes.
This patch just has that function check for NFS_INO_INVALID_DATA in
addition to NFS_INO_REVAL_PAGECACHE. This fixes the bug, but looking
over the code, I wonder if we might have a similar bug in
nfs_revalidate_size(). The difference between those two flags is very
subtle, so it seems like we ought to be checking for
NFS_INO_INVALID_DATA in most of the places that we look for
NFS_INO_REVAL_PAGECACHE.
I believe this is regression introduced by commit 8d197a568. The code
did check for NFS_INO_INVALID_DATA prior to that patch.
Original bug report is here:
https://bugzilla.redhat.com/show_bug.cgi?id=885743
Reported-by: Jian Li <jiali@redhat.com>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4d436f1d25a6bf4788dfc5eeed043137b47115f3
Author: Bryan Schumaker <bjschuma@netapp.com>
Date: Mon Nov 12 16:55:38 2012 -0500
NFS: Add sequence_priviliged_ops for nfs4_proc_sequence()
commit 6bdb5f213c4344324f600dde885f25768fbd14db upstream.
If I mount an NFS v4.1 server to a single client multiple times and then
run xfstests over each mountpoint I usually get the client into a state
where recovery deadlocks. The server informs the client of a
cb_path_down sequence error, the client then does a
bind_connection_to_session and checks the status of the lease.
I found that bind_connection_to_session sets the NFS4_SESSION_DRAINING
flag on the client, but this flag is never unset before
nfs4_check_lease() reaches nfs4_proc_sequence(). This causes the client
to deadlock, halting all NFS activity to the server. nfs4_proc_sequence()
is only called by the state manager, so I can change it to run in privileged
mode to bypass the NFS4_SESSION_DRAINING check and avoid the deadlock.
Signed-off-by: Bryan Schumaker <bjschuma@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b500eb39c56d89b45c088cba868f20abcfd63cbf
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date: Fri Jan 4 23:00:54 2013 +0100
ACPI / scan: Do not use dummy HID for system bus ACPI nodes
commit 4f5f64cf0cc916220aaa055992e31195470cfe37 upstream.
At one point acpi_device_set_id() checks if acpi_device_hid(device)
returns NULL, but that never happens, so system bus devices with an
empty list of PNP IDs are given the dummy HID ("device") instead of
the "system bus HID" ("LNXSYBUS"). Fix the code to use the right
check.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 100865b4ba20cbe67875b4acf1c0a6711afd41ef
Author: Aaron Lu <aaron.lu@intel.com>
Date: Mon Nov 26 13:55:25 2012 +0800
libata: restore acpi disable functionality
commit 0d0cdb028f9d9771e2b346038707734121f906e3 upstream.
Commit 66fa7f215 "libata-acpi: improve ACPI disabling" introdcued the
behaviour of disabling ATA ACPI if ata_acpi_on_devcfg failed the 2nd
time, but commit 30dcf76ac dropped this behaviour and this caused
problem for Dimitris Damigos, where his laptop can not resume correctly.
The bugzilla page for it is:
https://bugzilla.kernel.org/show_bug.cgi?id=49331
The problem is, ata_dev_push_id will fail the 2nd time it is invoked,
and due to disabling ACPI code is dropped, ata_acpi_on_devcfg which
calls ata_dev_push_id will keep failing and eventually made the device
disabled.
This patch restores the original behaviour, if acpi failed the 2nd time,
disable acpi functionality for the device(and we do not event need to
add a debug message for this as it is still there ;-).
Reported-by: Dimitris Damigos <damigos@freemail.gr>
Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b8d74ea021f1b07c4d09c8f6b8b7689e4488abe5
Author: Zhang Rui <rui.zhang@intel.com>
Date: Fri Nov 30 12:57:03 2012 +0100
ACPI: do acpisleep dmi check when CONFIG_ACPI_SLEEP is set
commit 0ac1b1d7b7424cd6f129b5454b504b3cae746f0e upstream.
The current acpisleep DMI checks only run when CONFIG_SUSPEND is set.
And this may break hibernation on some platforms when CONFIG_SUSPEND
is cleared.
Move acpisleep DMI check into #ifdef CONFIG_ACPI_SLEEP instead.
[rjw: Added acpi_sleep_dmi_check() and rebased on top of earlier
patches adding entries to acpisleep_dmi_table[].]
References: https://bugzilla.kernel.org/show_bug.cgi?id=45921
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 192847f2597e954488a175e40607dcb396bec6c1
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date: Mon Oct 22 22:15:00 2012 +0200
usb: gadget: network: fix bind() error path
commit e79cc615a9bb44da72c499ccfa2c9c4bbea3aa84 upstream.
I think this is wrong since 72c973dd ("usb: gadget: add
usb_endpoint_descriptor to struct usb_ep"). If we fail to allocate an ep
or bail out early we shouldn't check for the descriptor which is
assigned at ep_enable() time.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Tatyana Brokhman <tlinder@codeaurora.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 065f5561a20659cf17aae5f72b32b5c2695c8e00
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date: Mon Oct 22 22:15:05 2012 +0200
usb: gadget: uvc: fix error path in uvc_function_bind()
commit 0f9df939385527049c8062a099fbfa1479fe7ce0 upstream.
The "video->minor = -1" assigment is done in V4L2 by
video_register_device() so it is removed here.
Now. uvc_function_bind() calls in error case uvc_function_unbind() for
cleanup. The problem is that uvc_function_unbind() frees the uvc struct
and uvc_bind_config() does as well in error case of usb_add_function().
Removing kfree() in usb_add_function() would make the patch smaller but
it would look odd because the new allocated memory is not cleaned up.
However it is not guaranteed that if we call usb_add_function() we also
get to the bind function.
Therefore the patch extracts the conditional cleanup from
uvc_function_unbind() applies to uvc_function_bind().
uvc_function_unbind() now contains only the complete cleanup which is
required once everything has been registrated.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Bhupesh Sharma <bhupesh.sharma@st.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7347f50b3f034bd4da7778e55ce91076bf3f39c6
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date: Mon Oct 22 22:14:56 2012 +0200
usb: gadget: tcm_usb_gadget: NULL terminate the FS descriptor list
commit fad8deb274edcef1c8ca38946338f5f4f8126fe2 upstream.
The descriptor list for FS speed was not NULL terminated. This patch
fixes this.
While here one of the twe two bAlternateSetting assignments for the BOT
interface. Both assign 0, one is enough.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f3aab9240ef932c777727b3165ef583eaa9ab5a7
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date: Mon Oct 22 22:15:04 2012 +0200
usb: gadget: phonet: free requests in pn_bind()'s error path
commit d0eca719dd11ad0619e8dd6a1f3eceb95b0216dd upstream.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 364b6ddb217bb3c08ca1d02fc39efae277624d27
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date: Mon Oct 22 22:15:02 2012 +0200
usb: gadget: midi: free hs descriptors
commit d185039f7982eb82cf8d03b6fb6689587ca5af24 upstream.
The HS descriptors are only created if HS is supported by the UDC but we
never free them.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8af66623ab9c6d0c8b1517d578f7f3ad1e323cc9
Author: Lothar Waßmann <LW@KARO-electronics.de>
Date: Thu Nov 22 10:11:25 2012 +0100
USB: chipidea: fix use after free bug
commit 98c35534420d3147553bd3071a5fc63cd56de5b1 upstream.
The pointer to a platform_device struct must not be dereferenced after
the device has been unregistered.
This bug produces a crash when unloading the ci13xxx kernel module
compiled with CONFIG_PAGE_POISONING enabled.
Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
Acked-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7564b3b7f18d55c017346ae061f5359872e0a281
Author: Christian Lamparter <chunkeey@googlemail.com>
Date: Thu Dec 27 15:18:20 2012 +0100
p54usb: add USBIDs for two more p54usb devices
commit 4010fe21a315b4223c25376714c6a2b61b722e5c upstream.
This patch adds USBIDs for:
- DrayTek Vigor 530
- Zoom 4410a
It also adds a note about Gemtek WUBI-100GW
and SparkLAN WL-682 USBID conflict [WUBI-100GW
is a ISL3886+NET2280 (LM86 firmare) solution,
whereas WL-682 is a ISL3887 (LM87 firmware)]
device.
Source: <http://www.wikidevi.com/wiki/Intersil/p54/usb/windows>
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ea32c619bde5c88e0a53b4f98883efc07038305f
Author: Tomasz Guszkowski <tsg@o2.pl>
Date: Sat Dec 22 18:30:01 2012 +0100
p54usb: add USB ID for T-Com Sinus 154 data II
commit 3194b7fcdf6caea338b5d2c72d76fed80437649c upstream.
Added USB ID for T-Com Sinus 154 data II.
Signed-off-by: Tomasz Guszkowski <tsg@o2.pl>
Acked-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ffbbf80d13d77ef0b533d7410dd2097f37dd24c2
Author: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Date: Thu Dec 20 16:24:43 2012 +0200
rtlwifi: fix incorrect use of usb_alloc_coherent with usb_control_msg
commit 4c3de5920c486b8eefa6187ee6a181864c161100 upstream.
Incorrect use of usb_alloc_coherent memory as input buffer to usb_control_msg
can cause problems in arch DMA code, for example kernel BUG at
'arch/arm/include/asm/dma-mapping.h:321' on ARM (linux-3.4).
Change _usb_writeN_sync use kmalloc'd buffer instead.
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e6ad3201c5b9c54cf09fd30d420378f0a9476780
Author: Dan Williams <dcbw@redhat.com>
Date: Mon Dec 17 08:17:41 2012 +0000
qmi_wwan/cdc_ether: add Dell Wireless 5800 (Novatel E362) USB IDs
commit 0370acd4d4d2595a11b0b0a793acb506e19b9d4c upstream.
Signed-off-by: Dan Williams <dcbw@redhat.com>
Acked-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b862579a9398a1c68a99a6f1edb53fb1837c3737
Author: David Henningsson <david.henningsson@canonical.com>
Date: Mon Jan 7 12:03:47 2013 +0100
ALSA: hda - add mute LED for HP Pavilion 17 (Realtek codec)
commit 6d3cd5d444223c41eabb70dccff14fae4e8cb8b1 upstream.
The mute LED is in this case connected to the Mic1 VREF.
The machine also exposes the following string in BIOS:
"HP_Mute_LED_0_A", so if more machines are coming, it probably
makes sense to try to do something more generic, like for the
IDT codec.
BugLink: https://bugs.launchpad.net/bugs/1096789
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit de9cd896f7f3a43440a88f56a71826382227eddc
Author: Takashi Iwai <tiwai@suse.de>
Date: Thu Dec 13 14:33:42 2012 +0100
ALSA: hda - Fix pin configuration of HP Pavilion dv7
commit 8ae5865ec77c22462c736846a0679947a6953548 upstream.
Fix the quirk entry for HP Pavilion dv7 in order to make the bass
speaker working.
Reported-and-tested-by: Tomas Pospisek <tpo2@sourcepole.ch>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit db7a240b19ac3e8bcad0520f3575b3036b44b75b
Author: Takashi Iwai <tiwai@suse.de>
Date: Mon Dec 17 20:06:49 2012 +0100
ALSA: hda - Fix the wrong pincaps set in ALC861VD dallas/hp fixup
commit b78562b10fa66175e30b76073e32a0ad8d92aa83 upstream.
The workaround to force VREF50 for dallas/hp model with ALC861VD
was introduced in commit 8fdcb6fe4204bdb4c6991652717ab5063751414e,
but it contained wrong pincap override bits.
This patch fixes to exclude VREF80 pincap bit correctly.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2626d16bbdedcd64c6af3c519aecd5a6f2356e58
Author: Takashi Iwai <tiwai@suse.de>
Date: Fri Dec 14 10:22:35 2012 +0100
ALSA: hda - Always turn on pins for HDMI/DP
commit 6169b673618bf0b2518ce413b54925782a603f06 upstream.
We've seen the broken HDMI *video* output on some machines with GM965,
and the debugging session pointed that the culprit is the disabled
audio output pins. Toggling these pins dynamically on demand caused
flickering of HDMI TV.
This patch changes the behavior to keep the pin ON constantly.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=51421
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 13602ca9cbb1ef190bdda351ccbfc75d8c92fd74
Author: Takashi Iwai <tiwai@suse.de>
Date: Wed Dec 12 12:10:01 2012 +0100
ALSA: hda - Add stereo-dmic fixup for Acer Aspire One 522
commit 63a077e27648b4043b1ca1b4e29f0c42d99616b6 upstream.
Acer Aspire One 522 has the infamous digital mic unit that needs the
phase inversion fixup for stereo.
Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=715737
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit eeada90a5340368310a59c4b620982055fb022f0
Author: Takashi Iwai <tiwai@suse.de>
Date: Wed Dec 12 11:50:12 2012 +0100
ALSA: hda - Move runtime PM check to runtime_idle callback
commit 6eb827d23577a4efec2b10a9c4cc9ded268a1d1c upstream.
The runtime_idle callback is the right place to check the suspend
capability, but currently we do it wrongly in the runtime_suspend
callback. This leads to a kernel error message like:
pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x50 [snd_hda_intel] returns -11
and the runtime PM core would even repeat the attempts.
Reported-and-tested-by: Borislav Petkov <bp@alien8.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8be35acfe0265662971b77b09bced6cf28781325
Author: Takashi Iwai <tiwai@suse.de>
Date: Mon Dec 3 11:30:50 2012 +0100
ALSA: usb-audio: Fix missing autopm for MIDI input
commit f5f165418cabf2218eb466c0e94693b8b1aee88b upstream.
The commit [88a8516a: ALSA: usbaudio: implement USB autosuspend] added
the support of autopm for USB MIDI output, but it didn't take the MIDI
input into account.
This patch adds the following for fixing the autopm:
- Manage the URB start at the first MIDI input stream open, instead of
the time of instance creation
- Move autopm code to the common substream_open()
- Make snd_usbmidi_input_start/_stop() more robust and add the running
state check
Reviewd-by: Clemens Ladisch <clemens@ladisch.de>
Tested-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 08588e3a7dc15d729b145a6d589af5f1ca8fa7ba
Author: Takashi Iwai <tiwai@suse.de>
Date: Mon Dec 3 11:12:46 2012 +0100
ALSA: usb-audio: Avoid autopm calls after disconnection
commit 59866da9e4ae54819e3c4e0a8f426bdb0c2ef993 upstream.
Add a similar protection against the disconnection race and the
invalid use of usb instance after disconnection, as well as we've done
for the USB audio PCM.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=51201
Reviewd-by: Clemens Ladisch <clemens@ladisch.de>
Tested-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 680dfe59174a569b842cbcb1cecaf517923e8fc1
Author: Hugh Dickins <hughd@google.com>
Date: Wed Jan 2 02:01:33 2013 -0800
tmpfs mempolicy: fix /proc/mounts corrupting memory
commit f2a07f40dbc603c15f8b06e6ec7f768af67b424f upstream.
Recently I suggested using "mount -o remount,mpol=local /tmp" in NUMA
mempolicy testing. Very nasty. Reading /proc/mounts, /proc/pid/mounts
or /proc/pid/mountinfo may then corrupt one bit of kernel memory, often
in a page table (causing "Bad swap" or "Bad page map" warning or "Bad
pagetable" oops), sometimes in a vm_area_struct or rbnode or somewhere
worse. "mpol=prefer" and "mpol=prefer:Node" are equally toxic.
Recent NUMA enhancements are not to blame: this dates back to 2.6.35,
when commit e17f74af351c "mempolicy: don't call mpol_set_nodemask() when
no_context" skipped mpol_parse_str()'s call to mpol_set_nodemask(),
which used to initialize v.preferred_node, or set MPOL_F_LOCAL in flags.
With slab poisoning, you can then rely on mpol_to_str() to set the bit
for node 0x6b6b, probably in the next page above the caller's stack.
mpol_parse_str() is only called from shmem_parse_options(): no_context
is always true, so call it unused for now, and remove !no_context code.
Set v.nodes or v.preferred_node or MPOL_F_LOCAL as mpol_to_str() might
expect. Then mpol_to_str() can ignore its no_context argument also,
the mpol being appropriately initialized whether contextualized or not.
Rename its no_context unused too, and let subsequent patch remove them
(that's not needed for stable backporting, which would involve rejects).
I don't understand why MPOL_LOCAL is described as a pseudo-policy:
it's a reasonable policy which suffers from a confusing implementation
in terms of MPOL_PREFERRED with MPOL_F_LOCAL. I believe this would be
much more robust if MPOL_LOCAL were recognized in switch statements
throughout, MPOL_F_LOCAL deleted, and MPOL_PREFERRED use the (possibly
empty) nodes mask like everyone else, instead of its preferred_node
variant (I presume an optimization from the days before MPOL_LOCAL).
But that would take me too long to get right and fully tested.
Signed-off-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 59c66ed69072ccb09c10d06b79339ebfb25a5394
Author: Christoffer Dall <cdall@cs.columbia.edu>
Date: Fri Dec 21 13:03:50 2012 -0500
mm: Fix PageHead when !CONFIG_PAGEFLAGS_EXTENDED
commit ad4b3fb7ff9940bcdb1e4cd62bd189d10fa636ba upstream.
Unfortunately with !CONFIG_PAGEFLAGS_EXTENDED, (!PageHead) is false, and
(PageHead) is true, for tail pages. If this is indeed the intended
behavior, which I doubt because it breaks cache cleaning on some ARM
systems, then the nomenclature is highly problematic.
This patch makes sure PageHead is only true for head pages and PageTail
is only true for tail pages, and neither is true for non-compound pages.
[ This buglet seems ancient - seems to have been introduced back in Apr
2008 in commit 6a1e7f777f61: "pageflags: convert to the use of new
macros". And the reason nobody noticed is because the PageHead()
tests are almost all about just sanity-checking, and only used on
pages that are actual page heads. The fact that the old code returned
true for tail pages too was thus not really noticeable. - Linus ]
Signed-off-by: Christoffer Dall <cdall@cs.columbia.edu>
Acked-by: Andrea Arcangeli <aarcange@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Will Deacon <Will.Deacon@arm.com>
Cc: Steve Capper <Steve.Capper@arm.com>
Cc: Christoph Lameter <cl@linux.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9359dd031b11100a3532ef7bfc04f2fc7f23c33b
Author: Sonny Rao <sonnyrao@chromium.org>
Date: Thu Dec 20 15:05:07 2012 -0800
mm: fix calculation of dirtyable memory
commit c8b74c2f6604923de91f8aa6539f8bb934736754 upstream.
The system uses global_dirtyable_memory() to calculate number of
dirtyable pages/pages that can be allocated to the page cache. A bug
causes an underflow thus making the page count look like a big unsigned
number. This in turn confuses the dirty writeback throttling to
aggressively write back pages as they become dirty (usually 1 page at a
time). This generally only affects systems with highmem because the
underflowed count gets subtracted from the global count of dirtyable
memory.
The problem was introduced with v3.2-4896-gab8fabd
Fix is to ensure we don't get an underflowed total of either highmem or
global dirtyable memory.
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Signed-off-by: Puneet Kumar <puneetster@chromium.org>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Tested-by: Damien Wyart <damien.wyart@free.fr>
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@linuxfoundation.org>
commit 4250fc1e957d8b86f124593ecdad534009b89733
Author: Will Deacon <will.deacon@arm.com>
Date: Fri Oct 19 14:03:33 2012 +0100
virtio: force vring descriptors to be allocated from lowmem
commit b92b1b89a33c172c075edccf6afb0edc41d851fd upstream.
Virtio devices may attempt to add descriptors to a virtqueue from atomic
context using GFP_ATOMIC allocation. This is problematic because such
allocations can fall outside of the lowmem mapping, causing virt_to_phys
to report bogus physical addresses which are subsequently passed to
userspace via the buffers for the virtual device.
This patch masks out __GFP_HIGH and __GFP_HIGHMEM from the requested
flags when allocating descriptors for a virtqueue. If an atomic
allocation is requested and later fails, we will return -ENOSPC which
will be handled by the driver.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Cc: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7420b25f0873f561e70c7cda716587014cee95c3
Author: Will Deacon <will.deacon@arm.com>
Date: Fri Oct 19 14:03:32 2012 +0100
virtio: 9p: correctly pass physical address to userspace for high pages
commit b9cdc88df8e63e81c723b82c286fc97f5d0dc325 upstream.
When using a virtio transport, the 9p net device may pass the physical
address of a kernel buffer to userspace via a scatterlist inside a
virtqueue. If the kernel buffer is mapped outside of the linear mapping
(e.g. highmem), then virt_to_page will return a bogus value and we will
populate the scatterlist with junk.
This patch uses kmap_to_page when populating the page array for a kernel
buffer.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Cc: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4a8d5b926259721cf7b931967b8e3f9e3936c2d7
Author: Will Deacon <will.deacon@arm.com>
Date: Fri Oct 19 14:03:31 2012 +0100
mm: highmem: export kmap_to_page for modules
commit f0263d2d222e9e25f2587e51a9dc58c6fb2a9352 upstream.
Some virtio device drivers (9p) need to translate high virtual addresses
to physical addresses, which are inserted into the virtqueue for
processing by userspace.
This patch exports the kmap_to_page symbol, so that the affected drivers
can be compiled as modules.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2dfc7a391af637b6a820c0ded3964c2b9efd417f
Author: Ondrej Zary <linux@rainbow-software.org>
Date: Tue Dec 11 22:18:05 2012 +0100
x86, 8042: Enable A20 using KBC to fix S3 resume on some MSI laptops
commit ad68652412276f68ad4fe3e1ecf5ee6880876783 upstream.
Some MSI laptop BIOSes are broken - INT 15h code uses port 92h to enable A20
line but resume code assumes that KBC was used.
The laptop will not resume from S3 otherwise but powers off after a while
and then powers on again stuck with a blank screen.
Fix it by enabling A20 using KBC in i8042_platform_init for x86.
Fixes https://bugzilla.kernel.org/show_bug.cgi?id=12878
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Link: http://lkml.kernel.org/r/201212112218.06551.linux@rainbow-software.org
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7dafc8952dc0964cead9646039a8d66a9ed4cf73
Author: Will Deacon <will.deacon@arm.com>
Date: Fri Nov 23 12:34:13 2012 +0000
arm64: signal: push the unwinding prologue on the signal stack
commit 304ef4e8367244b547734143c792a2ab764831e8 upstream.
To allow debuggers to unwind through signal frames, we create a fake
stack unwinding prologue containing the link register and frame pointer
of the interrupted context. The signal frame is then offset by 16 bytes
to make room for the two saved registers which are pushed onto the frame
of the *interrupted* context, rather than placed directly above the
signal stack.
This doesn't work when an alternative signal stack is set up for a SEGV
handler, which is raised in response to RLIMIT_STACK being reached. In
this case, we try to push the unwinding prologue onto the full stack and
subsequently take a fault which we fail to resolve, causing setup_return
to return -EFAULT and handle_signal to force_sigsegv on the current task.
This patch fixes the problem by including the unwinding prologue as part
of the rt_sigframe definition, which is populated during setup_sigframe,
ensuring that it always ends up on the signal stack.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a5220f902e102b27f529ffe3b9ef221583378597
Author: Catalin Marinas <catalin.marinas@arm.com>
Date: Wed Nov 28 17:06:05 2012 +0000
arm64: Make !dirty ptes read-only
commit 33eaa58f854770dc9c98411a356c98e3a53edfda upstream.
The AArch64 Linux port relies on the mm code to wrprotect clean ptes.
This however is not the case with newly created ptes and
PAGE_SHARED(_EXEC) is writable but !dirty.
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 21838dbf96ce1e94d1ba80fdd491f9a0a6352ff1
Author: Kees Cook <keescook@chromium.org>
Date: Thu Dec 20 15:05:16 2012 -0800
exec: do not leave bprm->interp on stack
commit b66c5984017533316fd1951770302649baf1aa33 upstream.
If a series of scripts are executed, each triggering module loading via
unprintable bytes in the script header, kernel stack contents can leak
into the command line.
Normally execution of binfmt_script and binfmt_misc happens recursively.
However, when modules are enabled, and unprintable bytes exist in the
bprm->buf, execution will restart after attempting to load matching
binfmt modules. Unfortunately, the logic in binfmt_script and
binfmt_misc does not expect to get restarted. They leave bprm->interp
pointing to their local stack. This means on restart bprm->interp is
left pointing into unused stack memory which can then be copied into the
userspace argv areas.
After additional study, it seems that both recursion and restart remains
the desirable way to handle exec with scripts, misc, and modules. As
such, we need to protect the changes to interp.
This changes the logic to require allocation for any changes to the
bprm->interp. To avoid adding a new kmalloc to every exec, the default
value is left as-is. Only when passing through binfmt_script or
binfmt_misc does an allocation take place.
For a proof of concept, see DoTest.sh from:
http://www.halfdog.net/Security/2012/LinuxKernelBinfmtScriptStackDataDisclosure/
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: halfdog <me@halfdog.net>
Cc: P J P <ppandit@redhat.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
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@linuxfoundation.org>
commit cae5b83f40f584969767996e294a0cd322856c8b
Author: Robin Holt <holt@sgi.com>
Date: Thu Dec 20 15:05:50 2012 -0800
SGI-XP: handle non-fatal traps
commit 891348ca0f66206f1dc0e30d63757e3df1ae2d15 upstream.
We found a user code which was raising a divide-by-zero trap. That trap
would lead to XPC connections between system-partitions being torn down
due to the die_chain notifier callouts it received.
This also revealed a different issue where multiple callers into
xpc_die_deactivate() would all attempt to do the disconnect in parallel
which would sometimes lock up but often overwhelm the console on very
large machines as each would print at least one line of output at the
end of the deactivate.
I reviewed all the users of the die_chain notifier and changed the code
to ignore the notifier callouts for reasons which will not actually lead
to a system to continue on to call die().
[akpm@linux-foundation.org: fix ia64]
Signed-off-by: Robin Holt <holt@sgi.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@elte.hu>
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@linuxfoundation.org>
commit fe33f310343a8b2d733a8ab286c0f6b9bae08ed6
Author: Alan Cox <alan@lxorguk.ukuu.org.uk>
Date: Fri Dec 7 23:11:14 2012 +0100
pnpacpi: fix incorrect TEST_ALPHA() test
commit cdc87c5a30f407ed1ce43d8a22261116873d5ef1 upstream.
TEST_ALPHA() is broken and always returns 0.
[akpm@linux-foundation.org: return false for '@' as well, per Bjorn]
Signed-off-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c0343ba858128ce45ca9350922f53b7f03a1d590
Author: Felix Fietkau <nbd@openwrt.org>
Date: Mon Dec 10 17:40:21 2012 +0100
b43: fix tx path skb leaks
commit 78f18df4b323d2ac14d6c82e2fc3c8dc4556bccc upstream.
ieee80211_free_txskb() needs to be used instead of dev_kfree_skb_any for
tx packets passed to the driver from mac80211
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6a9c6804719aa5c6e17037b947875ed614c2e7b2
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date: Thu Dec 6 21:55:16 2012 -0600
b43legacy: Fix firmware loading when driver is built into the kernel
commit 576d28a7c73013717311cfcb514dbcae27c82eeb upstream.
Recent versions of udev cause synchronous firmware loading from the
probe routine to fail because the request to user space times out.
The original fix for b43legacy (commit a3ea2c7) moved the firmware
load from the probe routine to a work queue, but it still used synchronous
firmware loading. This method is OK when b43legacy is built as a module;
however, it fails when the driver is compiled into the kernel.
This version changes the code to load the initial firmware file
using request_firmware_nowait(). A completion event is used to
hold the work queue until that file is available. The remaining
firmware files are read synchronously.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 235db1e98f49a39427b87b491388cf645406e5fc
Author: Chuansheng Liu <chuansheng.liu@intel.com>
Date: Sat Nov 10 01:27:22 2012 +0800
firmware loader: Fix the concurrent request_firmware() race for kref_get/put
commit bd9eb7fbe69111ea0ff1f999ef4a5f26d223d1d5 upstream.
There is one race that both request_firmware() with the same
firmware name.
The race scenerio is as below:
CPU1 CPU2
request_firmware() -->
_request_firmware_load() return err another request_firmware() is coming -->
_request_firmware_cleanup is called --> _request_firmware_prepare -->
release_firmware ---> fw_lookup_and_allocate_buf -->
spin_lock(&fwc->lock)
... __fw_lookup_buf() return true
fw_free_buf() will be called --> ...
kref_put -->
decrease the refcount to 0
kref_get(&tmp->ref) ==> it will trigger warning
due to refcount == 0
__fw_free_buf() -->
... spin_unlock(&fwc->lock)
spin_lock(&fwc->lock)
list_del(&buf->list)
spin_unlock(&fwc->lock)
kfree(buf)
After that, the freed buf will be used.
The key race is decreasing refcount to 0 and list_del is not protected together by
fwc->lock, and it is possible another thread try to get it between refcount==0
and list_del.
Fix it here to protect it together.
Acked-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: liu chuansheng <chuansheng.liu@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 42b5489a2b5163c01e2fe23a609d397facfd0509
Author: Chuansheng Liu <chuansheng.liu@intel.com>
Date: Thu Nov 8 19:14:40 2012 +0800
firmware loader: Fix the race FW_STATUS_DONE is followed by class_timeout
commit ce2fcbd99cef580623116bb33531dbc3e6f690b0 upstream.
There is a race as below when calling request_firmware():
CPU1 CPU2
write 0 > loading
mutex_lock(&fw_lock)
...
set_bit FW_STATUS_DONE class_timeout is coming
set_bit FW_STATUS_ABORT
complete_all &completion
...
mutex_unlock(&fw_lock)
In this time, the bit FW_STATUS_DONE and FW_STATUS_ABORT are set,
and request_firmware() will return failure due to condition in
_request_firmware_load():
if (!buf->size || test_bit(FW_STATUS_ABORT, &buf->status))
retval = -ENOENT;
But from the above scenerio, it should be a successful requesting.
So we need judge if the bit FW_STATUS_DONE is already set before
calling fw_load_abort() in timeout function.
As Ming's proposal, we need change the timer into sched_work to
benefit from using &fw_lock mutex also.
Signed-off-by: liu chuansheng <chuansheng.liu@intel.com>
Acked-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e66e367bf75bb2e153f286a76592c2e23afc660d
Author: Eric Dumazet <edumazet@google.com>
Date: Mon Dec 10 12:32:03 2012 +0000
net: fix a race in gro_cell_poll()
[ Upstream commit f8e8f97c11d5ff3cc47d85b97c7c35e443dcf490 ]
Dmitry Kravkov reported packet drops for GRE packets since GRO support
was added.
There is a race in gro_cell_poll() because we call napi_complete()
without any synchronization with a concurrent gro_cells_receive()
Once bug was triggered, we queued packets but did not schedule NAPI
poll.
We can fix this issue using the spinlock protected the napi_skbs queue,
as we have to hold it to perform skb dequeue anyway.
As we open-code skb_dequeue(), we no longer need to mask IRQS, as both
producer and consumer run under BH context.
Bug added in commit c9e6bc644e (net: add gro_cells infrastructure)
Reported-by: Dmitry Kravkov <dmitry@broadcom.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Tested-by: Dmitry Kravkov <dmitry@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>