commit e6577f3189d82a729b13e38f3d135f1becd6d294 Author: Greg Kroah-Hartman Date: Fri Jan 11 09:19:28 2013 -0800 Linux 3.7.2 commit 1dcfb28724803c27657b335dbb8f4494067d10e5 Author: Jeff Layton 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 Signed-off-by: Jeff Layton Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 862dc356d36fd84c5673af61364447bd38b453c6 Author: Jeff Layton 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 Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 76e59b0f305a6f2e2ebcfdb8c14750d08ff037ba Author: Alexander Stein 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 Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 50e54c2c8d010f933b49176b33961e7ad72c0c33 Author: Ben Hutchings 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 References: http://bugs.debian.org/694546 Signed-off-by: Ben Hutchings Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit e4ada2b44499ce77e6053679e1f60cad42611b91 Author: Guenter Roeck 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 Reported-by: Juergen Beisert Tested-by: Juergen Beisert Cc: Jean Delvare Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 787f7301074ccd07a3e82236ca41eefd245f4e07 Author: Michal Hocko 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 Cc: Mel Gorman Cc: Rik van Riel Cc: Peter Zijlstra Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit bc2eb9ea9eae3cd2485dad9bb1541f18dffa6c5c Author: Tony Prisk 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 Signed-off-by: Tony Prisk Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit a28690b32d01b12edb03da62b1180b83fdc5a8b3 Author: Tony Prisk 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 Cc: Edgar Toernig Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 287376ad9f4cf330c786ac84d9f6a416d9ac0d09 Author: Andrew Morton 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 Acked-by: Alexander Holler Cc: Vincent Palatin Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 423fccba308720afd02ec192c9ca59a167ca3717 Author: Corey Minyard 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 Cc: Jesper Nilsson Cc: Mikael Starvik Acked-by: Geert Uytterhoeven Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 3f0f3b1f1d41775078ee2f2a12b148191d5ac8de Author: Artem Bityutskiy 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//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//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 Acked-by: Serge E. Hallyn Acked-by: Kees Cook Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 65bacde551e409a27dd86dae3801e3726b97ca28 Author: Stephen Boyd 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: /-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 Tested-by: Tony Lindgren Cc: Eric W. Biederman Signed-off-by: Stephen Boyd Signed-off-by: Linus Torvalds Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 3d8c1e480a910cf0940f7b375875b567a5a9a771 Author: Gustavo Padovan 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 ] _raw_spin_lock+0xd/0x10 [28084.104021] [] sco_conn_del+0x58/0x1b0 [bluetooth] [28084.104021] [] sco_connect_cfm+0xb9/0x2b0 [bluetooth] [28084.104021] [] hci_sync_conn_complete_evt.isra.94+0x1c9/0x260 [bluetooth] [28084.104021] [] hci_event_packet+0x74d/0x2b40 [bluetooth] [28084.104021] [] ? __kfree_skb+0x3d/0x90 [28084.104021] [] ? kfree_skb+0x36/0x90 [28084.104021] [] ? hci_send_to_monitor+0x10e/0x190 [bluetooth] [28084.104021] [] ? hci_send_to_monitor+0x10e/0x190 [bluetooth] Reported-by: Chan-yeol Park Signed-off-by: Gustavo Padovan Signed-off-by: Greg Kroah-Hartman commit c7cf062d05129d6d75dabfcb96f5c5a4a92d824c Author: Gustavo Padovan 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] [] ? debug_print_object+0x8e/0xb0 [ 1434.210760] [] warn_slowpath_common+0x87/0xb0 [ 1434.210760] [] warn_slowpath_fmt+0x41/0x50 [ 1434.210760] [] debug_print_object+0x8e/0xb0 [ 1434.210760] [] ? hci_dev_open+0x310/0x310 [ 1434.210760] [] ? _raw_spin_unlock_irqrestore+0x55/0xa0 [ 1434.210760] [] __debug_check_no_obj_freed+0xa5/0x230 [ 1434.210760] [] ? bt_host_release+0x10/0x20 [ 1434.210760] [] debug_check_no_obj_freed+0x15/0x20 [ 1434.210760] [] kfree+0x227/0x330 [ 1434.210760] [] bt_host_release+0x10/0x20 [ 1434.210760] [] device_release+0x65/0xc0 [ 1434.210760] [] kobject_cleanup+0x145/0x190 [ 1434.210760] [] kobject_release+0xd/0x10 [ 1434.210760] [] kobject_put+0x4c/0x60 [ 1434.210760] [] put_device+0x12/0x20 [ 1434.210760] [] hci_free_dev+0x24/0x30 [ 1434.210760] [] vhci_release+0x31/0x60 [ 1434.210760] [] __fput+0x122/0x250 [ 1434.210760] [] ? rcu_user_exit+0x9d/0xd0 [ 1434.210760] [] ____fput+0x9/0x10 [ 1434.210760] [] task_work_run+0xb2/0xf0 [ 1434.210760] [] do_notify_resume+0x77/0xa0 [ 1434.210760] [] int_signal+0x12/0x17 [ 1434.210760] ---[ end trace a6d57fefbc8a8cc7 ]--- Reported-by: Sasha Levin Signed-off-by: Gustavo Padovan Signed-off-by: Greg Kroah-Hartman commit 5795b170bfde23d424fb15d2c945d5dfb827e063 Author: Gustavo Padovan 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: [] 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: [] 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 Signed-off-by: Greg Kroah-Hartman commit 2ea3e85ea577adc61acef73b3b83da5ed781da99 Author: Jeff Cook 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 Signed-off-by: Gustavo Padovan Signed-off-by: Greg Kroah-Hartman commit 63be10e5ace81580bd2944aa2f283d75bd2f0a01 Author: Myron Stowe 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 Reference: https://bugzilla.kernel.org/show_bug.cgi?id=51331 Signed-off-by: Myron Stowe Signed-off-by: Bjorn Helgaas Signed-off-by: Greg Kroah-Hartman commit dc0e6fecca56cc2ad5c8ce9023e1be6737441cb3 Author: Huang Ying 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 Tested-by: Sarah Sharp Signed-off-by: Huang Ying Signed-off-by: Bjorn Helgaas Acked-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit c9b184487ae4e1ec9c8d11b4ed1a23293fabb2ce Author: Andy Lutomirski 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 Signed-off-by: Bjorn Helgaas Acked-by: Chris Ball CC: Manoj Iyer Signed-off-by: Greg Kroah-Hartman commit 0635ca9a8069d8b12debcf0e99cab47a5437997f Author: Huang Ying 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 Signed-off-by: Bjorn Helgaas Acked-by: Alan Stern Acked-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 6e9fd9fbb4f2dd2506e708af835e39d00264d8e6 Author: David Woodhouse 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 Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 756c3f692b7c5158dfe545fe56c517b6e065688b Author: Jeff Layton 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 Signed-off-by: Jeff Layton Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 7696b6d4dcfbc9fb8bd4c91774424197a4b2cc39 Author: Jeff Layton 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: [] 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:[] [] 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] [] smb_send_rqst+0x71/0x1f0 [cifs] [90701.828991] [] ? schedule+0x29/0x70 [90701.834736] [] smb_sendv+0x3d/0x40 [cifs] [90701.841062] [] smb_send+0x26/0x30 [cifs] [90701.847291] [] send_nt_cancel+0x6f/0xd0 [cifs] [90701.854102] [] SendReceive+0x18e/0x360 [cifs] [90701.860814] [] CIFSFindFirst+0x1a8/0x3f0 [cifs] [90701.867724] [] ? build_path_from_dentry+0xf1/0x260 [cifs] [90701.875601] [] ? build_path_from_dentry+0xf1/0x260 [cifs] [90701.883477] [] cifs_query_dir_first+0x26/0x30 [cifs] [90701.890869] [] initiate_cifs_search+0xed/0x250 [cifs] [90701.898354] [] ? fillonedir+0x100/0x100 [90701.904486] [] cifs_readdir+0x45b/0x8f0 [cifs] [90701.911288] [] ? fillonedir+0x100/0x100 [90701.917410] [] ? fillonedir+0x100/0x100 [90701.923533] [] ? fillonedir+0x100/0x100 [90701.929657] [] vfs_readdir+0xb8/0xe0 [90701.935490] [] sys_getdents+0x8f/0x110 [90701.941521] [] 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 [] kernel_setsockopt+0x2e/0x60 [90701.977125] RSP [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 Signed-off-by: Jeff Layton Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit ff68026c74ea60403004010c4cc1f81b1f4faa2a Author: Jan Kara 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: [] mnt_drop_write+0x24/0x30 but there are no more locks to release! Reported-by: Zdenek Kabelac Signed-off-by: Jan Kara Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit bbe614b3f9a1cab9cdd88ecdd9415bd3dd04efd3 Author: Will Deacon 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 Tested-by: Guennadi Liakhovetski Signed-off-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 4faefc4ea2f866e9d924f47eacea45a114b8d0d1 Author: Will Deacon 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 Tested-by: Florian Fainelli Signed-off-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit f41983f43cfa6643ff0d1f1c310d4d3eb3412770 Author: Al Viro 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 Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 3f6c363d7bf291a026e4c3d2abe1d0767b0468e1 Author: Will Deacon 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 Acked-by: Catalin Marinas Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 7a13eba369913bfd2f363b722d2831db5c3669df Author: Al Viro 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 Acked-by: Will Deacon Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit f8b723cc9f1a9eec83c8527d67eedc6249b7fb66 Author: Dave Chinner 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 Reviewed-by: Christoph Hellwig Signed-off-by: Ben Myers Signed-off-by: Greg Kroah-Hartman commit 82251473514fde36ce8dc0167f41eaf7ef6a4cb9 Author: Dave Chinner 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 Reviewed-by: Christoph Hellwig Reviewed-by: Andrew Dahl Signed-off-by: Ben Myers Signed-off-by: Greg Kroah-Hartman commit 5a88b8abb0a0f7b4611daaf5305c6cc08cdf5d2b Author: Oleg Nesterov 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 Signed-off-by: Oleg Nesterov Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit bcfab4b51440df476ed319f44c21043ceb317198 Author: Roland Dreier 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 Signed-off-by: Greg Kroah-Hartman Cc: Joe Perches Cc: Sylvain Munaut Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 191199ac78d4707fbf1e841224d62e2672bd6902 Author: Eric Dumazet 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 Bisected-by: Willy Tarreau Tested-by: Willy Tarreau Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b5810b8da2248adc73a1bf3def752d99beb87cca Author: Daniel Borkmann 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 Signed-off-by: Daniel Borkmann Acked-by: Vlad Yasevich Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 316899aceab5510d296f9437e410401409e9ce19 Author: Stefan Hasko 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 Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit ae51878d61c4b39eae37d1bf29032e185b8e6501 Author: Alexander Aring 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 Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 29a21388c86ffa0d18018a7ddf49aa129588a339 Author: Duan Jiong 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 Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 9ce4b845ed059b9104f3bb204db6306e52b25d1b Author: Christoph Paasch 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: [] kmemleak_alloc+0x21/0x3e [] kmem_cache_alloc+0xb5/0xc5 [] sk_prot_alloc.isra.53+0x2b/0xcd [] sk_clone_lock+0x16/0x21e [] inet_csk_clone_lock+0x10/0x7b [] tcp_create_openreq_child+0x21/0x481 [] tcp_v4_syn_recv_sock+0x3a/0x23b [] tcp_check_req+0x29f/0x416 [] tcp_v4_do_rcv+0x161/0x2bc [] tcp_v4_rcv+0x6c9/0x701 [] ip_local_deliver_finish+0x70/0xc4 [] ip_local_deliver+0x4e/0x7f [] ip_rcv_finish+0x1fc/0x233 [] ip_rcv+0x217/0x267 [] __netif_receive_skb+0x49e/0x553 [] 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 Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 6558b40d737d831bad3214a40eac72b226190673 Author: Akinobu Mita 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 Acked-by: Antonio Quartulli Cc: Marek Lindner Cc: Simon Wunderlich Cc: Antonio Quartulli Cc: b.a.t.m.a.n@lists.open-mesh.org Cc: "David S. Miller" Cc: netdev@vger.kernel.org Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit d7371e1b63cf51b89415381bff47b7312cdcef77 Author: David S. Miller 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 Signed-off-by: Greg Kroah-Hartman commit 7716902f6503082b33b7dc79a09467ed110cc95b Author: David S. Miller 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 Signed-off-by: Greg Kroah-Hartman commit a74864cb91b49bc6c54f1358dd07a12135b510f7 Author: David S. Miller 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 Signed-off-by: Greg Kroah-Hartman commit fe4ddcf94392f83f27b690f32cdd162ccd0f7eb3 Author: David S. Miller 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 Signed-off-by: Greg Kroah-Hartman commit 6d2446753d8fa56e2dbc7147965a063b37bbdf56 Author: David S. Miller 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 Signed-off-by: Greg Kroah-Hartman commit 0041cdc62ea0350c4be9b7d7dfb03d89310c8765 Author: David S. Miller 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 Signed-off-by: Greg Kroah-Hartman commit 98a4f4ed3db015aa4755d1f6d39c6a03bc29c5d5 Author: Dave Kleikamp 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 Cc: "David S. Miller" Cc: sparclinux@vger.kernel.org Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit a288c9a403bc7d8b9fb6d97183a691aac793337b Author: Tejun Heo 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 Cc: Oleg Nesterov Cc: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit e1593cb019046a8e29442a3376d8b30230e6a15d Author: Steve French 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 Reviewed-by: Jeff Layton Signed-off-by: Greg Kroah-Hartman commit 4fc832846b7e2afb0775be4521bcd801c60eba1f Author: Andy Gross 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 Signed-off-by: Greg Kroah-Hartman commit 61001c0a21fef142d5a462db15810afbcd95b416 Author: Jianguo Wu 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 Signed-off-by: Jiang Liu Reviewed-by: Aneesh Kumar K.V Acked-by: Michal Hocko Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 5778e9e966423d834a01de616f29c6bf834c0d8a Author: Gao feng 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 Acked-by: Li Zefan Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit d36994375807d655612b0a3f3967e8039bb41100 Author: Tejun Heo 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:[] [] 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: [] done_path_create+0x19/0x50 [] sys_mkdirat+0x59/0x80 [] sys_mkdir+0x19/0x20 [] 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 [] dput+0x1dc/0x1e0 RSP ---[ end trace 1277bcfd9561ddb0 ]--- Fix it by dropping the unnecessary dget/dput() pair. Signed-off-by: Tejun Heo Acked-by: Li Zefan Signed-off-by: Greg Kroah-Hartman commit 838a4f8bb1a039ee4ea6de544624d8fd620bf455 Author: Tejun Heo 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 Cc: Oleg Nesterov Cc: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 27f0a83c49a639749f9e26c5af4b70164922f304 Author: Russell Webb 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 Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman commit 702b2581032ced74efff3f908a3c3133947198fc Author: Alexis R. Cortes 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 Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman commit d0abdff42cb550ae036f9ac3aa168ea7c867f464 Author: Alan Stern 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 Reported-and-tested-by: Matthias Schniedermeyer CC: Sarah Sharp Signed-off-by: Greg Kroah-Hartman commit 3f853877eee9cf53adcce9a52b25db56ff763941 Author: Julius Werner 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 Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman commit 056f8bdd03a4a9e3237295696909cee11a3bb651 Author: Sarah Sharp 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 Reported-by: Chintan Mehta Reported-by: Shimmer Huang Tested-by: Bhavik Kothari Tested-by: Shimmer Huang Signed-off-by: Greg Kroah-Hartman commit 3f605c4b4424a7042bd3ba656af10e3a405d5663 Author: Sarah Sharp 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 Reported-by: David Binderman Signed-off-by: Greg Kroah-Hartman commit 2a90b6baab1021ebbd7fdbb4b894ea315650d360 Author: Afzal Mohammed 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 Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit d18d223714855658c62d17fdd8721bb00ad3cd69 Author: Sergei Shtylyov 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 Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit fc34a7d5ad5dc9df67bbc9969824fb0949dcceb0 Author: Thomas Gleixner 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 Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1209041738200.2754@ionos Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit dfcffbb7f048e69812ad92a293ea71a6514e4077 Author: Dmitry Torokhov 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 Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit d9f5f4bc9a6ca2558588eee434027b0b2af2f121 Author: Gabor Juhos 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 Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 459825b716b4f7f71d3d0a0da9c7e4192eb371c6 Author: Christophe TORDEUX 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 Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 2bf3364673ef36af85003ead8247313f78df515a Author: Diego Calleja 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 Reviewed-by: Ping Cheng Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit df433c41eb955760b92949c2d7a229ace30789db Author: Peter Popovec 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 Signed-off-by: Peter Popovec Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit dfde3c6d130f2e679024bd7b8692a4d00bac4ef8 Author: NeilBrown 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 Cc: Trond Myklebust Cc: Al Viro Signed-off-by: Andrew Morton Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 2fc2d6907a79876e6c9dc3d3cd4565b319756750 Author: Nickolai Zeldovich 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 Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 25191192f7f136dbad081a19cd72521789268f2a Author: Trond Myklebust 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 Cc: Weston Andros Adamson Cc: Tejun Heo Cc: Bruce Fields Signed-off-by: Greg Kroah-Hartman commit bb3330c18aa9340c600706e60de7d8fdf5260420 Author: Xi Wang 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 Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 0b7d74eb80d06be3b5792cbdd2c77d1ccb05cc4b Author: Yanchuan Nian 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 Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 5865afd9e73a8981f38344ddcb42d9f2049c1469 Author: Weston Andros Adamson 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 Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit e13ddf6bbcfe7ea1f83b9a7a9f698ef461cdff82 Author: Neil Brown 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 [bfields: use OWNER_OVERRIDE and update for 4.1] Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit e5926fdb4ef0eac63dee54009a74878e53777716 Author: J. Bruce Fields 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 Signed-off-by: Greg Kroah-Hartman commit 9dbe75d2b4111884596c498ca0acbaf71952ae97 Author: J. Bruce Fields 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 Signed-off-by: Greg Kroah-Hartman commit 7063a3eea85cf9246cdc917096d25d96f1cc341a Author: Yanchuan Nian 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 Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 4cc423d6e6a6f0003c8e757d47aacec58e729f21 Author: Trond Myklebust 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 Tested-by: Neil Brown Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit fe32340b7fc58c8323eca13e111367be75d61918 Author: Trond Myklebust 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] [] dump_trace+0xaa/0x2b0 [634155.004641] [] dump_stack+0x69/0x6f [634155.004653] [] warn_slowpath_common+0x7b/0xc0 [634155.004662] [] drop_nlink+0x34/0x40 [634155.004687] [] nfs_dentry_iput+0x33/0x70 [nfs] [634155.004714] [] dput+0x12e/0x230 [634155.004726] [] __fput+0x170/0x230 [634155.004735] [] filp_close+0x5f/0x90 [634155.004743] [] sys_close+0x97/0x100 [634155.004754] [] system_call_fastpath+0x16/0x1b [634155.004767] [<00007f2a73a0d110>] 0x7f2a73a0d10f Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 22ad97385fd0d4d7d28f54c6a504203e5f498c9e Author: NeilBrown 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 Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 9883793305d5fbcf79c565f3572ba44d2493f8f5 Author: Jeff Layton 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 Cc: Fred Isaman Signed-off-by: Jeff Layton Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 43d1640924a2bd61e5f8ad156930353bd410e36d Author: Sven Wegener 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 Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 62ec24f42255d4c140a77f206068b76262c01c53 Author: Jeff Layton 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 Signed-off-by: Jeff Layton Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 4d436f1d25a6bf4788dfc5eeed043137b47115f3 Author: Bryan Schumaker 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 Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit b500eb39c56d89b45c088cba868f20abcfd63cbf Author: Rafael J. Wysocki 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 Signed-off-by: Greg Kroah-Hartman commit 100865b4ba20cbe67875b4acf1c0a6711afd41ef Author: Aaron Lu 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 Signed-off-by: Aaron Lu Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman commit b8d74ea021f1b07c4d09c8f6b8b7689e4488abe5 Author: Zhang Rui 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 Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 192847f2597e954488a175e40607dcb396bec6c1 Author: Sebastian Andrzej Siewior 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 Cc: Tatyana Brokhman Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 065f5561a20659cf17aae5f72b32b5c2695c8e00 Author: Sebastian Andrzej Siewior 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 Cc: Laurent Pinchart Cc: Bhupesh Sharma Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 7347f50b3f034bd4da7778e55ce91076bf3f39c6 Author: Sebastian Andrzej Siewior 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 Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit f3aab9240ef932c777727b3165ef583eaa9ab5a7 Author: Sebastian Andrzej Siewior 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 Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 364b6ddb217bb3c08ca1d02fc39efae277624d27 Author: Sebastian Andrzej Siewior 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 Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 8af66623ab9c6d0c8b1517d578f7f3ad1e323cc9 Author: Lothar Waßmann 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 Acked-by: Alexander Shishkin Signed-off-by: Greg Kroah-Hartman commit 7564b3b7f18d55c017346ae061f5359872e0a281 Author: Christian Lamparter 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: Signed-off-by: Christian Lamparter Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit ea32c619bde5c88e0a53b4f98883efc07038305f Author: Tomasz Guszkowski 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 Acked-by: Christian Lamparter Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit ffbbf80d13d77ef0b533d7410dd2097f37dd24c2 Author: Jussi Kivilinna 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 Acked-by: Larry Finger Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit e6ad3201c5b9c54cf09fd30d420378f0a9476780 Author: Dan Williams 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 Acked-by: Bjørn Mork Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b862579a9398a1c68a99a6f1edb53fb1837c3737 Author: David Henningsson 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 Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit de9cd896f7f3a43440a88f56a71826382227eddc Author: Takashi Iwai 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 Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit db7a240b19ac3e8bcad0520f3575b3036b44b75b Author: Takashi Iwai 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 Signed-off-by: Greg Kroah-Hartman commit 2626d16bbdedcd64c6af3c519aecd5a6f2356e58 Author: Takashi Iwai 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 Signed-off-by: Greg Kroah-Hartman commit 13602ca9cbb1ef190bdda351ccbfc75d8c92fd74 Author: Takashi Iwai 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 Signed-off-by: Greg Kroah-Hartman commit eeada90a5340368310a59c4b620982055fb022f0 Author: Takashi Iwai 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 Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 8be35acfe0265662971b77b09bced6cf28781325 Author: Takashi Iwai 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 Tested-by: Clemens Ladisch Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 08588e3a7dc15d729b145a6d589af5f1ca8fa7ba Author: Takashi Iwai 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 Tested-by: Clemens Ladisch Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 680dfe59174a569b842cbcb1cecaf517923e8fc1 Author: Hugh Dickins 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 Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 59c66ed69072ccb09c10d06b79339ebfb25a5394 Author: Christoffer Dall 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 Acked-by: Andrea Arcangeli Cc: Andrew Morton Cc: Will Deacon Cc: Steve Capper Cc: Christoph Lameter Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 9359dd031b11100a3532ef7bfc04f2fc7f23c33b Author: Sonny Rao 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 Signed-off-by: Puneet Kumar Acked-by: Johannes Weiner Tested-by: Damien Wyart Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 4250fc1e957d8b86f124593ecdad534009b89733 Author: Will Deacon 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 Cc: Sasha Levin Signed-off-by: Rusty Russell Signed-off-by: Greg Kroah-Hartman commit 7420b25f0873f561e70c7cda716587014cee95c3 Author: Will Deacon 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 Cc: Sasha Levin Signed-off-by: Rusty Russell Signed-off-by: Greg Kroah-Hartman commit 4a8d5b926259721cf7b931967b8e3f9e3936c2d7 Author: Will Deacon 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 Signed-off-by: Rusty Russell Signed-off-by: Greg Kroah-Hartman commit 2dfc7a391af637b6a820c0ded3964c2b9efd417f Author: Ondrej Zary 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 Cc: Dmitry Torokhov Cc: Alan Cox Cc: Rafael J. Wysocki Link: http://lkml.kernel.org/r/201212112218.06551.linux@rainbow-software.org Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit 7dafc8952dc0964cead9646039a8d66a9ed4cf73 Author: Will Deacon 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 Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit a5220f902e102b27f529ffe3b9ef221583378597 Author: Catalin Marinas 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 Signed-off-by: Greg Kroah-Hartman commit 21838dbf96ce1e94d1ba80fdd491f9a0a6352ff1 Author: Kees Cook 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 Cc: halfdog Cc: P J P Cc: Alexander Viro Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit cae5b83f40f584969767996e294a0cd322856c8b Author: Robin Holt 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 Cc: Thomas Gleixner Cc: Ingo Molnar Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit fe33f310343a8b2d733a8ab286c0f6b9bae08ed6 Author: Alan Cox 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 Signed-off-by: Andrew Morton Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit c0343ba858128ce45ca9350922f53b7f03a1d590 Author: Felix Fietkau 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 Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 6a9c6804719aa5c6e17037b947875ed614c2e7b2 Author: Larry Finger 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 Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 235db1e98f49a39427b87b491388cf645406e5fc Author: Chuansheng Liu 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 Signed-off-by: liu chuansheng Signed-off-by: Greg Kroah-Hartman commit 42b5489a2b5163c01e2fe23a609d397facfd0509 Author: Chuansheng Liu 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 Acked-by: Ming Lei Signed-off-by: Greg Kroah-Hartman commit e66e367bf75bb2e153f286a76592c2e23afc660d Author: Eric Dumazet 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 Signed-off-by: Eric Dumazet Tested-by: Dmitry Kravkov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman