commit 7fd7a446b1c2b96252e4389746e5419eae04faef Author: Zefan Li Date: Mon Dec 1 18:02:45 2014 +0800 Linux 3.4.105 commit 4290973d9aa3a5ff64acb03e004762260e8271a4 Author: Guillaume Nault Date: Wed Sep 3 14:12:55 2014 +0200 l2tp: fix race while getting PMTU on PPP pseudo-wire commit eed4d839b0cdf9d84b0a9bc63de90fd5e1e886fb upstream. Use dst_entry held by sk_dst_get() to retrieve tunnel's PMTU. The dst_mtu(__sk_dst_get(tunnel->sock)) call was racy. __sk_dst_get() could return NULL if tunnel->sock->sk_dst_cache was reset just before the call, thus making dst_mtu() dereference a NULL pointer: [ 1937.661598] BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 [ 1937.664005] IP: [] pppol2tp_connect+0x33d/0x41e [l2tp_ppp] [ 1937.664005] PGD daf0c067 PUD d9f93067 PMD 0 [ 1937.664005] Oops: 0000 [#1] SMP [ 1937.664005] Modules linked in: l2tp_ppp l2tp_netlink l2tp_core ip6table_filter ip6_tables iptable_filter ip_tables ebtable_nat ebtables x_tables udp_tunnel pppoe pppox ppp_generic slhc deflate ctr twofish_generic twofish_x86_64_3way xts lrw gf128mul glue_helper twofish_x86_64 twofish_common blowfish_generic blowfish_x86_64 blowfish_common des_generic cbc xcbc rmd160 sha512_generic hmac crypto_null af_key xfrm_algo 8021q garp bridge stp llc tun atmtcp clip atm ext3 mbcache jbd iTCO_wdt coretemp kvm_intel iTCO_vendor_support kvm pcspkr evdev ehci_pci lpc_ich mfd_core i5400_edac edac_core i5k_amb shpchp button processor thermal_sys xfs crc32c_generic libcrc32c dm_mod usbhid sg hid sr_mod sd_mod cdrom crc_t10dif crct10dif_common ata_generic ahci ata_piix tg3 libahci libata uhci_hcd ptp ehci_hcd pps_core usbcore scsi_mod libphy usb_common [last unloaded: l2tp_core] [ 1937.664005] CPU: 0 PID: 10022 Comm: l2tpstress Tainted: G O 3.17.0-rc1 #1 [ 1937.664005] Hardware name: HP ProLiant DL160 G5, BIOS O12 08/22/2008 [ 1937.664005] task: ffff8800d8fda790 ti: ffff8800c43c4000 task.ti: ffff8800c43c4000 [ 1937.664005] RIP: 0010:[] [] pppol2tp_connect+0x33d/0x41e [l2tp_ppp] [ 1937.664005] RSP: 0018:ffff8800c43c7de8 EFLAGS: 00010282 [ 1937.664005] RAX: ffff8800da8a7240 RBX: ffff8800d8c64600 RCX: 000001c325a137b5 [ 1937.664005] RDX: 8c6318c6318c6320 RSI: 000000000000010c RDI: 0000000000000000 [ 1937.664005] RBP: ffff8800c43c7ea8 R08: 0000000000000000 R09: 0000000000000000 [ 1937.664005] R10: ffffffffa048e2c0 R11: ffff8800d8c64600 R12: ffff8800ca7a5000 [ 1937.664005] R13: ffff8800c439bf40 R14: 000000000000000c R15: 0000000000000009 [ 1937.664005] FS: 00007fd7f610f700(0000) GS:ffff88011a600000(0000) knlGS:0000000000000000 [ 1937.664005] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 1937.664005] CR2: 0000000000000020 CR3: 00000000d9d75000 CR4: 00000000000027e0 [ 1937.664005] Stack: [ 1937.664005] ffffffffa049da80 ffff8800d8fda790 000000000000005b ffff880000000009 [ 1937.664005] ffff8800daf3f200 0000000000000003 ffff8800c43c7e48 ffffffff81109b57 [ 1937.664005] ffffffff81109b0e ffffffff8114c566 0000000000000000 0000000000000000 [ 1937.664005] Call Trace: [ 1937.664005] [] ? pppol2tp_connect+0x235/0x41e [l2tp_ppp] [ 1937.664005] [] ? might_fault+0x9e/0xa5 [ 1937.664005] [] ? might_fault+0x55/0xa5 [ 1937.664005] [] ? rcu_read_unlock+0x1c/0x26 [ 1937.664005] [] SYSC_connect+0x87/0xb1 [ 1937.664005] [] ? sysret_check+0x1b/0x56 [ 1937.664005] [] ? trace_hardirqs_on_caller+0x145/0x1a1 [ 1937.664005] [] ? trace_hardirqs_on_thunk+0x3a/0x3f [ 1937.664005] [] ? spin_lock+0x9/0xb [ 1937.664005] [] SyS_connect+0x9/0xb [ 1937.664005] [] system_call_fastpath+0x16/0x1b [ 1937.664005] Code: 10 2a 84 81 e8 65 76 bd e0 65 ff 0c 25 10 bb 00 00 4d 85 ed 74 37 48 8b 85 60 ff ff ff 48 8b 80 88 01 00 00 48 8b b8 10 02 00 00 <48> 8b 47 20 ff 50 20 85 c0 74 0f 83 e8 28 89 83 10 01 00 00 89 [ 1937.664005] RIP [] pppol2tp_connect+0x33d/0x41e [l2tp_ppp] [ 1937.664005] RSP [ 1937.664005] CR2: 0000000000000020 [ 1939.559375] ---[ end trace 82d44500f28f8708 ]--- Fixes: f34c4a35d879 ("l2tp: take PMTU from tunnel UDP socket") Signed-off-by: Guillaume Nault Acked-by: Eric Dumazet Signed-off-by: David S. Miller Cc: Guillaume Nault Signed-off-by: Zefan Li commit 9024225cf3c5f0fe29e87aa46330d41816ca91b6 Author: Narendra K Date: Mon Jul 16 15:24:41 2012 +0000 ixgbevf: Prevent RX/TX statistics getting reset to zero commit 936597631dd310e220544dc5c6075d924efd39b2 upstream. The commit 4197aa7bb81877ebb06e4f2cc1b5fea2da23a7bd implements 64 bit per ring statistics. But the driver resets the 'total_bytes' and 'total_packets' from RX and TX rings in the RX and TX interrupt handlers to zero. This results in statistics being lost and user space reporting RX and TX statistics as zero. This patch addresses the issue by preventing the resetting of RX and TX ring statistics to zero. Signed-off-by: Narendra K Tested-by: Sibai Li Signed-off-by: Jeff Kirsher Signed-off-by: David S. Miller Cc: Weng Meiling Signed-off-by: Zefan Li commit 10d5d534765ccd203e34e3ccf5f67edba5e577c7 Author: Benjamin Poirier Date: Tue Jan 7 10:11:10 2014 -0500 net: Do not enable tx-nocache-copy by default commit cdb3f4a31b64c3a1c6eef40bc01ebc9594c58a8c upstream. There are many cases where this feature does not improve performance or even reduces it. For example, here are the results from tests that I've run using 3.12.6 on one Intel Xeon W3565 and one i7 920 connected by ixgbe adapters. The results are from the Xeon, but they're similar on the i7. All numbers report the mean±stddev over 10 runs of 10s. 1) latency tests similar to what is described in "c6e1a0d net: Allow no-cache copy from user on transmit" There is no statistically significant difference between tx-nocache-copy on/off. nic irqs spread out (one queue per cpu) 200x netperf -r 1400,1 tx-nocache-copy off 692000±1000 tps 50/90/95/99% latency (us): 275±2/643.8±0.4/799±1/2474.4±0.3 tx-nocache-copy on 693000±1000 tps 50/90/95/99% latency (us): 274±1/644.1±0.7/800±2/2474.5±0.7 200x netperf -r 14000,14000 tx-nocache-copy off 86450±80 tps 50/90/95/99% latency (us): 334.37±0.02/838±1/2100±20/3990±40 tx-nocache-copy on 86110±60 tps 50/90/95/99% latency (us): 334.28±0.01/837±2/2110±20/3990±20 2) single stream throughput tests tx-nocache-copy leads to higher service demand throughput cpu0 cpu1 demand (Gb/s) (Gcycle) (Gcycle) (cycle/B) nic irqs and netperf on cpu0 (1x netperf -T0,0 -t omni -- -d send) tx-nocache-copy off 9402±5 9.4±0.2 0.80±0.01 tx-nocache-copy on 9403±3 9.85±0.04 0.838±0.004 nic irqs on cpu0, netperf on cpu1 (1x netperf -T1,1 -t omni -- -d send) tx-nocache-copy off 9401±5 5.83±0.03 5.0±0.1 0.923±0.007 tx-nocache-copy on 9404±2 5.74±0.03 5.523±0.009 0.958±0.002 As a second example, here are some results from Eric Dumazet with latest net-next. tx-nocache-copy also leads to higher service demand (cpu is Intel(R) Xeon(R) CPU X5660 @ 2.80GHz) lpq83:~# ./ethtool -K eth0 tx-nocache-copy on lpq83:~# perf stat ./netperf -H lpq84 -c MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to lpq84.prod.google.com () port 0 AF_INET Recv Send Send Utilization Service Demand Socket Socket Message Elapsed Send Recv Send Recv Size Size Size Time Throughput local remote local remote bytes bytes bytes secs. 10^6bits/s % S % U us/KB us/KB 87380 16384 16384 10.00 9407.44 2.50 -1.00 0.522 -1.000 Performance counter stats for './netperf -H lpq84 -c': 4282.648396 task-clock # 0.423 CPUs utilized 9,348 context-switches # 0.002 M/sec 88 CPU-migrations # 0.021 K/sec 355 page-faults # 0.083 K/sec 11,812,797,651 cycles # 2.758 GHz [82.79%] 9,020,522,817 stalled-cycles-frontend # 76.36% frontend cycles idle [82.54%] 4,579,889,681 stalled-cycles-backend # 38.77% backend cycles idle [67.33%] 6,053,172,792 instructions # 0.51 insns per cycle # 1.49 stalled cycles per insn [83.64%] 597,275,583 branches # 139.464 M/sec [83.70%] 8,960,541 branch-misses # 1.50% of all branches [83.65%] 10.128990264 seconds time elapsed lpq83:~# ./ethtool -K eth0 tx-nocache-copy off lpq83:~# perf stat ./netperf -H lpq84 -c MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to lpq84.prod.google.com () port 0 AF_INET Recv Send Send Utilization Service Demand Socket Socket Message Elapsed Send Recv Send Recv Size Size Size Time Throughput local remote local remote bytes bytes bytes secs. 10^6bits/s % S % U us/KB us/KB 87380 16384 16384 10.00 9412.45 2.15 -1.00 0.449 -1.000 Performance counter stats for './netperf -H lpq84 -c': 2847.375441 task-clock # 0.281 CPUs utilized 11,632 context-switches # 0.004 M/sec 49 CPU-migrations # 0.017 K/sec 354 page-faults # 0.124 K/sec 7,646,889,749 cycles # 2.686 GHz [83.34%] 6,115,050,032 stalled-cycles-frontend # 79.97% frontend cycles idle [83.31%] 1,726,460,071 stalled-cycles-backend # 22.58% backend cycles idle [66.55%] 2,079,702,453 instructions # 0.27 insns per cycle # 2.94 stalled cycles per insn [83.22%] 363,773,213 branches # 127.757 M/sec [83.29%] 4,242,732 branch-misses # 1.17% of all branches [83.51%] 10.128449949 seconds time elapsed CC: Tom Herbert Signed-off-by: Benjamin Poirier Signed-off-by: David S. Miller Signed-off-by: Zefan Li commit c58038a16f106bf0b63068eaabbdc088ca70449f Author: Hannes Frederic Sowa Date: Fri Feb 21 02:55:35 2014 +0100 ipv6: reuse ip6_frag_id from ip6_ufo_append_data commit 916e4cf46d0204806c062c8c6c4d1f633852c5b6 upstream. Currently we generate a new fragmentation id on UFO segmentation. It is pretty hairy to identify the correct net namespace and dst there. Especially tunnels use IFF_XMIT_DST_RELEASE and thus have no skb_dst available at all. This causes unreliable or very predictable ipv6 fragmentation id generation while segmentation. Luckily we already have pregenerated the ip6_frag_id in ip6_ufo_append_data and can use it here. Signed-off-by: Hannes Frederic Sowa Signed-off-by: David S. Miller [bwh: Backported to 3.2: adjust filename, indentation] Signed-off-by: Ben Hutchings Signed-off-by: Zefan Li commit 4b7f15c26a453b1aa19965d515476700b8faaa0e Author: Ben Hutchings Date: Sat Apr 19 14:36:43 2014 +0100 rtl8192ce: Fix null dereference in watchdog Dmitry Semyonov reported that after upgrading from 3.2.54 to 3.2.57 the rtl8192ce driver will crash when its interface is brought up. The oops message shows: [ 1833.611397] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 [ 1833.611455] IP: [] rtl92ce_update_hal_rate_tbl+0x29/0x4db [rtl8192ce] ... [ 1833.613326] Call Trace: [ 1833.613346] [] ? rtl92c_dm_watchdog+0xd0b/0xec9 [rtl8192c_common] [ 1833.613391] [] ? process_one_work+0x161/0x269 [ 1833.613425] [] ? worker_thread+0xc2/0x145 [ 1833.613458] [] ? manage_workers.isra.25+0x15b/0x15b [ 1833.613496] [] ? kthread+0x76/0x7e [ 1833.613527] [] ? kernel_thread_helper+0x4/0x10 [ 1833.613563] [] ? kthread_worker_fn+0x139/0x139 [ 1833.613598] [] ? gs_change+0x13/0x13 Disassembly of rtl92ce_update_hal_rate_tbl() shows that the 'sta' parameter was null. None of the changes to the rtlwifi family between 3.2.54 and 3.2.57 seem to directly cause this, and reverting commit f78bccd79ba3 ('rtlwifi: rtl8192ce: Fix too long disable of IRQs') doesn't fix it. rtl92c_dm_watchdog() calls rtl92ce_update_hal_rate_tbl() via rtl92c_dm_refresh_rate_adaptive_mask(), which does not appear in the call trace as it was inlined. That function has been completely removed upstream which may explain why this crash wasn't seen there. I'm not sure that it is sensible to completely remove rtl92c_dm_refresh_rate_adaptive_mask() without making other compensating changes elsewhere, so try to work around this for 3.2 by checking for a null pointer in rtl92c_dm_refresh_rate_adaptive_mask() and then skipping the call to rtl92ce_update_hal_rate_tbl(). References: https://bugs.debian.org/745137 References: https://bugs.debian.org/745462 Reported-by: Dmitry Semyonov Signed-off-by: Ben Hutchings Cc: Larry Finger Cc: Chaoming Li Cc: Satoshi IWAMOTO Signed-off-by: Zefan Li commit 50f1b3d5a47088a67176ae72ffefda3e25873cf8 Author: Marcelo Ricardo Leitner Date: Mon Oct 13 14:03:30 2014 -0300 ipv4: disable bh while doing route gc Further tests revealed that after moving the garbage collector to a work queue and protecting it with a spinlock may leave the system prone to soft lockups if bottom half gets very busy. It was reproced with a set of firewall rules that REJECTed packets. If the NIC bottom half handler ends up running on the same CPU that is running the garbage collector on a very large cache, the garbage collector will not be able to do its job due to the amount of work needed for handling the REJECTs and also won't reschedule. The fix is to disable bottom half during the garbage collecting, as it already was in the first place (most calls to it came from softirqs). Signed-off-by: Marcelo Ricardo Leitner Acked-by: Hannes Frederic Sowa Acked-by: David S. Miller Signed-off-by: Ben Hutchings Signed-off-by: Zefan Li commit b54ca6089908121df8ea66545520c08048db7d80 Author: Marcelo Ricardo Leitner Date: Thu Aug 14 16:44:53 2014 -0300 ipv4: avoid parallel route cache gc executions When rt_intern_hash() has to deal with neighbour cache overflowing, it triggers the route cache garbage collector in an attempt to free some references on neighbour entries. Such call cannot be done async but should also not run in parallel with an already-running one, so that they don't collapse fighting over the hash lock entries. This patch thus blocks parallel executions with spinlocks: - A call from worker and from rt_intern_hash() are not the same, and cannot be merged, thus they will wait each other on rt_gc_lock. - Calls to gc from rt_intern_hash() may happen in parallel but we must wait for it to finish in order to try again. This dedup and synchrinozation is then performed by the locking just before calling __do_rt_garbage_collect(). Signed-off-by: Marcelo Ricardo Leitner Acked-by: Hannes Frederic Sowa Signed-off-by: Ben Hutchings Signed-off-by: Zefan Li commit b6153ead0de0592c14333a9d39b05bb92a3949b3 Author: Marcelo Ricardo Leitner Date: Thu Aug 14 16:44:52 2014 -0300 ipv4: move route garbage collector to work queue Currently the route garbage collector gets called by dst_alloc() if it have more entries than the threshold. But it's an expensive call, that don't really need to be done by then. Another issue with current way is that it allows running the garbage collector with the same start parameters on multiple CPUs at once, which is not optimal. A system may even soft lockup if the cache is big enough as the garbage collectors will be fighting over the hash lock entries. This patch thus moves the garbage collector to run asynchronously on a work queue, much similar to how rt_expire_check runs. There is one condition left that allows multiple executions, which is handled by the next patch. Signed-off-by: Marcelo Ricardo Leitner Acked-by: Hannes Frederic Sowa Signed-off-by: Ben Hutchings Signed-off-by: Zefan Li commit 23dd72fe868c722983999aaf13fa4ede1642a322 Author: James Bottomley Date: Fri Mar 28 10:50:17 2014 -0700 Fix spurious request sense in error handling commit d555a2abf3481f81303d835046a5ec2c4fb3ca8e upstream. We unconditionally execute scsi_eh_get_sense() to make sure all failed commands that should have sense attached, do. However, the routine forgets that some commands, because of the way they fail, will not have any sense code ... we should not bother them with a REQUEST_SENSE command. Fix this by testing to see if we actually got a CHECK_CONDITION return and skip asking for sense if we don't. Tested-by: Alan Stern Signed-off-by: James Bottomley Signed-off-by: Zefan Li commit be73621bd21353b97ba55fb5ad9b4c35aa09271a Author: Mikulas Patocka Date: Thu Aug 28 11:09:31 2014 -0400 dm crypt: fix access beyond the end of allocated space commit d49ec52ff6ddcda178fc2476a109cf1bd1fa19ed upstream. The DM crypt target accesses memory beyond allocated space resulting in a crash on 32 bit x86 systems. This bug is very old (it dates back to 2.6.25 commit 3a7f6c990ad04 "dm crypt: use async crypto"). However, this bug was masked by the fact that kmalloc rounds the size up to the next power of two. This bug wasn't exposed until 3.17-rc1 commit 298a9fa08a ("dm crypt: use per-bio data"). By switching to using per-bio data there was no longer any padding beyond the end of a dm-crypt allocated memory block. To minimize allocation overhead dm-crypt puts several structures into one block allocated with kmalloc. The block holds struct ablkcipher_request, cipher-specific scratch pad (crypto_ablkcipher_reqsize(any_tfm(cc))), struct dm_crypt_request and an initialization vector. The variable dmreq_start is set to offset of struct dm_crypt_request within this memory block. dm-crypt allocates the block with this size: cc->dmreq_start + sizeof(struct dm_crypt_request) + cc->iv_size. When accessing the initialization vector, dm-crypt uses the function iv_of_dmreq, which performs this calculation: ALIGN((unsigned long)(dmreq + 1), crypto_ablkcipher_alignmask(any_tfm(cc)) + 1). dm-crypt allocated "cc->iv_size" bytes beyond the end of dm_crypt_request structure. However, when dm-crypt accesses the initialization vector, it takes a pointer to the end of dm_crypt_request, aligns it, and then uses it as the initialization vector. If the end of dm_crypt_request is not aligned on a crypto_ablkcipher_alignmask(any_tfm(cc)) boundary the alignment causes the initialization vector to point beyond the allocated space. Fix this bug by calculating the variable iv_size_padding and adding it to the allocated size. Also correct the alignment of dm_crypt_request. struct dm_crypt_request is specific to dm-crypt (it isn't used by the crypto subsystem at all), so it is aligned on __alignof__(struct dm_crypt_request). Also align per_bio_data_size on ARCH_KMALLOC_MINALIGN, so that it is aligned as if the block was allocated with kmalloc. Reported-by: Krzysztof Kolasa Tested-by: Milan Broz Signed-off-by: Mikulas Patocka Signed-off-by: Mike Snitzer [lizf: Backported by Mikulas] Signed-off-by: Zefan Li commit b47d65db8f8e765ef0267d13681c9bf12a148fb5 Author: Eric W. Biederman Date: Mon Jul 28 16:26:53 2014 -0700 mnt: Only change user settable mount flags in remount commit a6138db815df5ee542d848318e5dae681590fccd upstream. Kenton Varda discovered that by remounting a read-only bind mount read-only in a user namespace the MNT_LOCK_READONLY bit would be cleared, allowing an unprivileged user to the remount a read-only mount read-write. Correct this by replacing the mask of mount flags to preserve with a mask of mount flags that may be changed, and preserve all others. This ensures that any future bugs with this mask and remount will fail in an easy to detect way where new mount flags simply won't change. Acked-by: Serge E. Hallyn Signed-off-by: "Eric W. Biederman" Cc: Francis Moreau Signed-off-by: Zefan Li commit ae552f6b54840fc7fb7a7ee688632b55e7eb9cef Author: Felipe Balbi Date: Wed Apr 23 09:58:26 2014 -0500 bluetooth: hci_ldisc: fix deadlock condition commit da64c27d3c93ee9f89956b9de86c4127eb244494 upstream. LDISCs shouldn't call tty->ops->write() from within ->write_wakeup(). ->write_wakeup() is called with port lock taken and IRQs disabled, tty->ops->write() will try to acquire the same port lock and we will deadlock. Acked-by: Marcel Holtmann Reviewed-by: Peter Hurley Reported-by: Huang Shijie Signed-off-by: Felipe Balbi Tested-by: Andreas Bießmann Signed-off-by: Greg Kroah-Hartman [tim.niemeyer@corscience.de: rebased on 3.4.103] Signed-off-by: Tim Niemeyer Signed-off-by: Zefan Li commit 2f1eef27008bd0abf9879e51a74fb9d0418634e8 Author: Pawel Moll Date: Fri Jun 13 16:03:32 2014 +0100 perf: Handle compat ioctl commit b3f207855f57b9c8f43a547a801340bb5cbc59e5 upstream. When running a 32-bit userspace on a 64-bit kernel (eg. i386 application on x86_64 kernel or 32-bit arm userspace on arm64 kernel) some of the perf ioctls must be treated with special care, as they have a pointer size encoded in the command. For example, PERF_EVENT_IOC_ID in 32-bit world will be encoded as 0x80042407, but 64-bit kernel will expect 0x80082407. In result the ioctl will fail returning -ENOTTY. This patch solves the problem by adding code fixing up the size as compat_ioctl file operation. Reported-by: Drew Richardson Signed-off-by: Pawel Moll Signed-off-by: Peter Zijlstra Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Link: http://lkml.kernel.org/r/1402671812-9078-1-git-send-email-pawel.moll@arm.com Signed-off-by: Ingo Molnar Cc: David Ahern [lizf: Backported to 3.4 by David Ahern] Signed-off-by: Zefan Li commit 69724a603fc759242348f931068b97c6634e40f9 Author: Sergio Gelato Date: Fri Oct 10 22:46:36 2014 +0800 NFS: fix stable regression BugLink: http://bugs.launchpad.net/bugs/1348670 Fix regression introduced in pre-3.14 kernels by cherry-picking aa07c713ecfc0522916f3cd57ac628ea6127c0ec (NFSD: Call ->set_acl with a NULL ACL structure if no entries). The affected code was removed in 3.14 by commit 4ac7249ea5a0ceef9f8269f63f33cc873c3fac61 (nfsd: use get_acl and ->set_acl). The ->set_acl methods are already able to cope with a NULL argument. Signed-off-by: Sergio Gelato Signed-off-by: Zefan Li commit efdbbff6f413513eb11aaa7bce3b289faee88f29 Author: Theodore Ts'o Date: Wed Sep 3 09:33:00 2014 -0400 ext4: avoid trying to kfree an ERR_PTR pointer commit a9cfcd63e8d206ce4235c355d857c4fbdf0f4587 upstream. Thanks to Dan Carpenter for extending smatch to find bugs like this. (This was found using a development version of smatch.) Fixes: 36de928641ee48b2078d3fe9514242aaa2f92013 Reported-by: Dan Carpenter [lizf: Backported to 3.4: - s/new.bh/new_bh/ - drop the change to ext4_cross_rename()] Signed-off-by: Zefan Li commit df22b9ebd5c3b63bfb2582470b53771bf276f252 Author: Theodore Ts'o Date: Sat Aug 23 17:47:19 2014 -0400 ext4: propagate errors up to ext4_find_entry()'s callers commit 36de928641ee48b2078d3fe9514242aaa2f92013 upstream. If we run into some kind of error, such as ENOMEM, while calling ext4_getblk() or ext4_dx_find_entry(), we need to make sure this error gets propagated up to ext4_find_entry() and then to its callers. This way, transient errors such as ENOMEM can get propagated to the VFS. This is important so that the system calls return the appropriate error, and also so that in the case of ext4_lookup(), we return an error instead of a NULL inode, since that will result in a negative dentry cache entry that will stick around long past the OOM condition which caused a transient ENOMEM error. Google-Bug-Id: #17142205 Signed-off-by: Theodore Ts'o [lizf: Backported to 3.4: - adjust context - s/old.bh/old_bh/g - s/new.bh/new_bh/g - drop the changes to ext4_find_delete_entry() and ext4_cross_rename() - add return value check for one more exr4_find_entry() in ext4_rename()] Signed-off-by: Zefan Li commit 50d6b91ac79a7ca600f62dbd917dec65e7751c85 Author: Johannes Berg Date: Wed Jul 30 14:55:26 2014 +0200 nl80211: clear skb cb before passing to netlink commit bd8c78e78d5011d8111bc2533ee73b13a3bd6c42 upstream. In testmode and vendor command reply/event SKBs we use the skb cb data to store nl80211 parameters between allocation and sending. This causes the code for CONFIG_NETLINK_MMAP to get confused, because it takes ownership of the skb cb data when the SKB is handed off to netlink, and it doesn't explicitly clear it. Clear the skb cb explicitly when we're done and before it gets passed to netlink to avoid this issue. Reported-by: Assaf Azulay Reported-by: David Spinadel Signed-off-by: Johannes Berg [lizf: Backported to 3.4: adjust context] Signed-off-by: Zefan Li commit 62db31b50ea97524defc93b74a851e6d7ca864ed Author: Jens Axboe Date: Tue Sep 16 13:38:51 2014 -0600 genhd: fix leftover might_sleep() in blk_free_devt() commit 46f341ffcfb5d8530f7d1e60f3be06cce6661b62 upstream. Commit 2da78092 changed the locking from a mutex to a spinlock, so we now longer sleep in this context. But there was a leftover might_sleep() in there, which now triggers since we do the final free from an RCU callback. Get rid of it. Reported-by: Pontus Fuchs Signed-off-by: Jens Axboe Signed-off-by: Zefan Li commit 48dd9ce77c7e5e4f4ad5be567bf0b939bbfb7872 Author: Josh Triplett Date: Fri Oct 3 16:00:54 2014 -0700 init/Kconfig: Hide printk log config if CONFIG_PRINTK=n commit 361e9dfbaae84b0b246ed18d1ab7c82a1a41b53e upstream. The buffers sized by CONFIG_LOG_BUF_SHIFT and CONFIG_LOG_CPU_MAX_BUF_SHIFT do not exist if CONFIG_PRINTK=n, so don't ask about their size at all. Signed-off-by: Josh Triplett Acked-by: Randy Dunlap [lizf: Backported to 3.4: - drop the change to CONFIG_LOG_CPU_MAX_BUF_SHIFT as it doesn't exist in 3.4] Signed-off-by: Zefan Li commit 232beb6ef710cf53def84d01276f59766b62756e Author: Peter Zijlstra Date: Thu Oct 2 16:17:02 2014 -0700 perf: fix perf bug in fork() commit 6c72e3501d0d62fc064d3680e5234f3463ec5a86 upstream. Oleg noticed that a cleanup by Sylvain actually uncovered a bug; by calling perf_event_free_task() when failing sched_fork() we will not yet have done the memset() on ->perf_event_ctxp[] and will therefore try and 'free' the inherited contexts, which are still in use by the parent process. This is bad.. Suggested-by: Oleg Nesterov Reported-by: Oleg Nesterov Reported-by: Sylvain 'ythier' Hitier Signed-off-by: Peter Zijlstra (Intel) Cc: Ingo Molnar Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Zefan Li commit ea38cd4170bdf0aa767d04df8363d08d5cc45dd2 Author: Mel Gorman Date: Thu Oct 2 19:47:41 2014 +0100 mm: migrate: Close race between migration completion and mprotect commit d3cb8bf6081b8b7a2dabb1264fe968fd870fa595 upstream. A migration entry is marked as write if pte_write was true at the time the entry was created. The VMA protections are not double checked when migration entries are being removed as mprotect marks write-migration-entries as read. It means that potentially we take a spurious fault to mark PTEs write again but it's straight-forward. However, there is a race between write migrations being marked read and migrations finishing. This potentially allows a PTE to be write that should have been read. Close this race by double checking the VMA permissions using maybe_mkwrite when migration completes. [torvalds@linux-foundation.org: use maybe_mkwrite] Signed-off-by: Mel Gorman Acked-by: Rik van Riel Signed-off-by: Linus Torvalds [lizf: Backported to 3.4: adjust context] Signed-off-by: Zefan Li commit e5b741351f667d05dd8be1a297202682d0cb4969 Author: Xiubo Li Date: Sun Sep 28 17:29:37 2014 +0800 ASoC: core: fix possible ZERO_SIZE_PTR pointer dereferencing error. commit 6596aa047b624aeec2ea321962cfdecf9953a383 upstream. Since we cannot make sure the 'params->num_regs' will always be none zero here, and then if it equals to zero, the kmemdup() will return ZERO_SIZE_PTR, which equals to ((void *)16). So this patch fix this with just doing the zero check before calling kmemdup(). Signed-off-by: Xiubo Li Signed-off-by: Mark Brown [lizf: Backported to 3.4: adjust context] Signed-off-by: Zefan Li commit 3efcfa5433a7c6ff5e04489398b1d7434f51b733 Author: Robin Murphy Date: Thu Sep 25 11:56:19 2014 +0100 ARM: 8165/1: alignment: don't break misaligned NEON load/store commit 5ca918e5e3f9df4634077c06585c42bc6a8d699a upstream. The alignment fixup incorrectly decodes faulting ARM VLDn/VSTn instructions (where the optional alignment hint is given but incorrect) as LDR/STR, leading to register corruption. Detect these and correctly treat them as unhandled, so that userspace gets the fault it expects. Reported-by: Simon Hosie Signed-off-by: Robin Murphy Signed-off-by: Russell King Signed-off-by: Zefan Li commit 8c3c6b9ee4d81b84b19dd07cb46d99fbf33850ab Author: Miklos Szeredi Date: Wed Sep 24 17:56:17 2014 +0200 shmem: fix nlink for rename overwrite directory commit b928095b0a7cff7fb9fcf4c706348ceb8ab2c295 upstream. If overwriting an empty directory with rename, then need to drop the extra nlink. Test prog: #include #include #include #include int main(void) { const char *test_dir1 = "test-dir1"; const char *test_dir2 = "test-dir2"; int res; int fd; struct stat statbuf; res = mkdir(test_dir1, 0777); if (res == -1) err(1, "mkdir(\"%s\")", test_dir1); res = mkdir(test_dir2, 0777); if (res == -1) err(1, "mkdir(\"%s\")", test_dir2); fd = open(test_dir2, O_RDONLY); if (fd == -1) err(1, "open(\"%s\")", test_dir2); res = rename(test_dir1, test_dir2); if (res == -1) err(1, "rename(\"%s\", \"%s\")", test_dir1, test_dir2); res = fstat(fd, &statbuf); if (res == -1) err(1, "fstat(%i)", fd); if (statbuf.st_nlink != 0) { fprintf(stderr, "nlink is %lu, should be 0\n", statbuf.st_nlink); return 1; } return 0; } Signed-off-by: Miklos Szeredi Signed-off-by: Al Viro Signed-off-by: Zefan Li commit 8b4675102596aa0f550fd7c32b9ed576b30e020a Author: Joseph Qi Date: Thu Sep 25 16:05:16 2014 -0700 ocfs2/dlm: do not get resource spinlock if lockres is new commit 5760a97c7143c208fa3a8f8cad0ed7dd672ebd28 upstream. There is a deadlock case which reported by Guozhonghua: https://oss.oracle.com/pipermail/ocfs2-devel/2014-September/010079.html This case is caused by &res->spinlock and &dlm->master_lock misordering in different threads. It was introduced by commit 8d400b81cc83 ("ocfs2/dlm: Clean up refmap helpers"). Since lockres is new, it doesn't not require the &res->spinlock. So remove it. Fixes: 8d400b81cc83 ("ocfs2/dlm: Clean up refmap helpers") Signed-off-by: Joseph Qi Reviewed-by: joyce.xue Reported-by: Guozhonghua Cc: Joel Becker Cc: Mark Fasheh Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Zefan Li commit 78d8eefded616224fc40ba2f9269bb53b7e6604e Author: Andreas Rohner Date: Thu Sep 25 16:05:14 2014 -0700 nilfs2: fix data loss with mmap() commit 56d7acc792c0d98f38f22058671ee715ff197023 upstream. This bug leads to reproducible silent data loss, despite the use of msync(), sync() and a clean unmount of the file system. It is easily reproducible with the following script: ----------------[BEGIN SCRIPT]-------------------- mkfs.nilfs2 -f /dev/sdb mount /dev/sdb /mnt dd if=/dev/zero bs=1M count=30 of=/mnt/testfile umount /mnt mount /dev/sdb /mnt CHECKSUM_BEFORE="$(md5sum /mnt/testfile)" /root/mmaptest/mmaptest /mnt/testfile 30 10 5 sync CHECKSUM_AFTER="$(md5sum /mnt/testfile)" umount /mnt mount /dev/sdb /mnt CHECKSUM_AFTER_REMOUNT="$(md5sum /mnt/testfile)" umount /mnt echo "BEFORE MMAP:\t$CHECKSUM_BEFORE" echo "AFTER MMAP:\t$CHECKSUM_AFTER" echo "AFTER REMOUNT:\t$CHECKSUM_AFTER_REMOUNT" ----------------[END SCRIPT]-------------------- The mmaptest tool looks something like this (very simplified, with error checking removed): ----------------[BEGIN mmaptest]-------------------- data = mmap(NULL, file_size - file_offset, PROT_READ | PROT_WRITE, MAP_SHARED, fd, file_offset); for (i = 0; i < write_count; ++i) { memcpy(data + i * 4096, buf, sizeof(buf)); msync(data, file_size - file_offset, MS_SYNC)) } ----------------[END mmaptest]-------------------- The output of the script looks something like this: BEFORE MMAP: 281ed1d5ae50e8419f9b978aab16de83 /mnt/testfile AFTER MMAP: 6604a1c31f10780331a6850371b3a313 /mnt/testfile AFTER REMOUNT: 281ed1d5ae50e8419f9b978aab16de83 /mnt/testfile So it is clear, that the changes done using mmap() do not survive a remount. This can be reproduced a 100% of the time. The problem was introduced in commit 136e8770cd5d ("nilfs2: fix issue of nilfs_set_page_dirty() for page at EOF boundary"). If the page was read with mpage_readpage() or mpage_readpages() for example, then it has no buffers attached to it. In that case page_has_buffers(page) in nilfs_set_page_dirty() will be false. Therefore nilfs_set_file_dirty() is never called and the pages are never collected and never written to disk. This patch fixes the problem by also calling nilfs_set_file_dirty() if the page has no buffers attached to it. [akpm@linux-foundation.org: s/PAGE_SHIFT/PAGE_CACHE_SHIFT/] Signed-off-by: Andreas Rohner Tested-by: Andreas Rohner Signed-off-by: Ryusuke Konishi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Zefan Li commit 504c4611c9da8b2cade4a45a31376293a4d53ed1 Author: Markos Chandras Date: Tue Sep 16 15:55:12 2014 +0100 MIPS: mcount: Adjust stack pointer for static trace in MIPS32 commit 8a574cfa2652545eb95595d38ac2a0bb501af0ae upstream. Every mcount() call in the MIPS 32-bit kernel is done as follows: [...] move at, ra jal _mcount addiu sp, sp, -8 [...] but upon returning from the mcount() function, the stack pointer is not adjusted properly. This is explained in details in 58b69401c797 (MIPS: Function tracer: Fix broken function tracing). Commit ad8c396936e3 ("MIPS: Unbreak function tracer for 64-bit kernel.) fixed the stack manipulation for 64-bit but it didn't fix it completely for MIPS32. Signed-off-by: Markos Chandras Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/7792/ Signed-off-by: Ralf Baechle Signed-off-by: Zefan Li commit 4fae6ccac642aa30d189dea30ef14306aad4d2d2 Author: Zefan Li Date: Thu Sep 25 09:41:02 2014 +0800 cpuset: PF_SPREAD_PAGE and PF_SPREAD_SLAB should be atomic flags commit 2ad654bc5e2b211e92f66da1d819e47d79a866f0 upstream. When we change cpuset.memory_spread_{page,slab}, cpuset will flip PF_SPREAD_{PAGE,SLAB} bit of tsk->flags for each task in that cpuset. This should be done using atomic bitops, but currently we don't, which is broken. Tetsuo reported a hard-to-reproduce kernel crash on RHEL6, which happened when one thread tried to clear PF_USED_MATH while at the same time another thread tried to flip PF_SPREAD_PAGE/PF_SPREAD_SLAB. They both operate on the same task. Here's the full report: https://lkml.org/lkml/2014/9/19/230 To fix this, we make PF_SPREAD_PAGE and PF_SPREAD_SLAB atomic flags. v4: - updated mm/slab.c. (Fengguang Wu) - updated Documentation. Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Miao Xie Cc: Kees Cook Fixes: 950592f7b991 ("cpusets: update tasks' page/slab spread flags in time") Reported-by: Tetsuo Handa Signed-off-by: Zefan Li Signed-off-by: Tejun Heo [lizf: Backported to 3.4: - adjust context - check current->flags & PF_MEMPOLICY rather than current->mempolicy] commit 699c06b386d592bede77d5a28ed1637c80ab99c0 Author: Zefan Li Date: Thu Sep 25 09:40:40 2014 +0800 sched: add macros to define bitops for task atomic flags commit e0e5070b20e01f0321f97db4e4e174f3f6b49e50 upstream. This will simplify code when we add new flags. v3: - Kees pointed out that no_new_privs should never be cleared, so we shouldn't define task_clear_no_new_privs(). we define 3 macros instead of a single one. v2: - updated scripts/tags.sh, suggested by Peter Cc: Ingo Molnar Cc: Miao Xie Cc: Tetsuo Handa Acked-by: Peter Zijlstra (Intel) Acked-by: Kees Cook Signed-off-by: Zefan Li Signed-off-by: Tejun Heo [lizf: Backported to 3.4: - adjust context - remove no_new_priv code - add atomic_flags to struct task_struct] commit f4d8504c6629c83dd6eec43a2eb7f34b9bae09a7 Author: Wanpeng Li Date: Wed Sep 24 16:38:05 2014 +0800 sched: Fix unreleased llc_shared_mask bit during CPU hotplug commit 03bd4e1f7265548832a76e7919a81f3137c44fd1 upstream. The following bug can be triggered by hot adding and removing a large number of xen domain0's vcpus repeatedly: BUG: unable to handle kernel NULL pointer dereference at 0000000000000004 IP: [..] find_busiest_group PGD 5a9d5067 PUD 13067 PMD 0 Oops: 0000 [#3] SMP [...] Call Trace: load_balance ? _raw_spin_unlock_irqrestore idle_balance __schedule schedule schedule_timeout ? lock_timer_base schedule_timeout_uninterruptible msleep lock_device_hotplug_sysfs online_store dev_attr_store sysfs_write_file vfs_write SyS_write system_call_fastpath Last level cache shared mask is built during CPU up and the build_sched_domain() routine takes advantage of it to setup the sched domain CPU topology. However, llc_shared_mask is not released during CPU disable, which leads to an invalid sched domainCPU topology. This patch fix it by releasing the llc_shared_mask correctly during CPU disable. Yasuaki also reported that this can happen on real hardware: https://lkml.org/lkml/2014/7/22/1018 His case is here: == Here is an example on my system. My system has 4 sockets and each socket has 15 cores and HT is enabled. In this case, each core of sockes is numbered as follows: | CPU# Socket#0 | 0-14 , 60-74 Socket#1 | 15-29, 75-89 Socket#2 | 30-44, 90-104 Socket#3 | 45-59, 105-119 Then llc_shared_mask of CPU#30 has 0x3fff80000001fffc0000000. It means that last level cache of Socket#2 is shared with CPU#30-44 and 90-104. When hot-removing socket#2 and #3, each core of sockets is numbered as follows: | CPU# Socket#0 | 0-14 , 60-74 Socket#1 | 15-29, 75-89 But llc_shared_mask is not cleared. So llc_shared_mask of CPU#30 remains having 0x3fff80000001fffc0000000. After that, when hot-adding socket#2 and #3, each core of sockets is numbered as follows: | CPU# Socket#0 | 0-14 , 60-74 Socket#1 | 15-29, 75-89 Socket#2 | 30-59 Socket#3 | 90-119 Then llc_shared_mask of CPU#30 becomes 0x3fff8000fffffffc0000000. It means that last level cache of Socket#2 is shared with CPU#30-59 and 90-104. So the mask has the wrong value. Signed-off-by: Wanpeng Li Tested-by: Linn Crosetto Reviewed-by: Borislav Petkov Reviewed-by: Toshi Kani Reviewed-by: Yasuaki Ishimatsu Cc: David Rientjes Cc: Prarit Bhargava Cc: Steven Rostedt Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/1411547885-48165-1-git-send-email-wanpeng.li@linux.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Zefan Li commit 6a77b9b1b47cd16ec052e50bda427e24e118e909 Author: John David Anglin Date: Mon Sep 22 20:54:50 2014 -0400 parisc: Only use -mfast-indirect-calls option for 32-bit kernel builds commit d26a7730b5874a5fa6779c62f4ad7c5065a94723 upstream. In spite of what the GCC manual says, the -mfast-indirect-calls has never been supported in the 64-bit parisc compiler. Indirect calls have always been done using function descriptors irrespective of the -mfast-indirect-calls option. Recently, it was noticed that a function descriptor was always requested when the -mfast-indirect-calls option was specified. This caused problems when the option was used in application code and doesn't make any sense because the whole point of the option is to avoid using a function descriptor for indirect calls. Fixing this broke 64-bit kernel builds. I will fix GCC but for now we need the attached change. This results in the same kernel code as before. Signed-off-by: John David Anglin Signed-off-by: Helge Deller Signed-off-by: Zefan Li commit 7433a2a7ac62c02e072069e51d69a511b2026d7f Author: Anton Altaparmakov Date: Mon Sep 22 01:53:03 2014 +0100 Fix nasty 32-bit overflow bug in buffer i/o code. commit f2d5a94436cc7cc0221b9a81bba2276a25187dd3 upstream. On 32-bit architectures, the legacy buffer_head functions are not always handling the sector number with the proper 64-bit types, and will thus fail on 4TB+ disks. Any code that uses __getblk() (and thus bread(), breadahead(), sb_bread(), sb_breadahead(), sb_getblk()), and calls it using a 64-bit block on a 32-bit arch (where "long" is 32-bit) causes an inifinite loop in __getblk_slow() with an infinite stream of errors logged to dmesg like this: __find_get_block_slow() failed. block=6740375944, b_blocknr=2445408648 b_state=0x00000020, b_size=512 device sda1 blocksize: 512 Note how in hex block is 0x191C1F988 and b_blocknr is 0x91C1F988 i.e. the top 32-bits are missing (in this case the 0x1 at the top). This is because grow_dev_page() is broken and has a 32-bit overflow due to shifting the page index value (a pgoff_t - which is just 32 bits on 32-bit architectures) left-shifted as the block number. But the top bits to get lost as the pgoff_t is not type cast to sector_t / 64-bit before the shift. This patch fixes this issue by type casting "index" to sector_t before doing the left shift. Note this is not a theoretical bug but has been seen in the field on a 4TiB hard drive with logical sector size 512 bytes. This patch has been verified to fix the infinite loop problem on 3.17-rc5 kernel using a 4TB disk image mounted using "-o loop". Without this patch doing a "find /nt" where /nt is an NTFS volume causes the inifinite loop 100% reproducibly whilst with the patch it works fine as expected. Signed-off-by: Anton Altaparmakov Signed-off-by: Linus Torvalds Signed-off-by: Zefan Li commit d7bbf15e60a6368bb958a52d2e8ac5a18fd4c37e Author: Clemens Ladisch Date: Sun Sep 21 22:50:57 2014 +0200 ALSA: pcm: fix fifo_size frame calculation commit a9960e6a293e6fc3ed414643bb4e4106272e4d0a upstream. The calculated frame size was wrong because snd_pcm_format_physical_width() actually returns the number of bits, not bytes. Use snd_pcm_format_size() instead, which not only returns bytes, but also simplifies the calculation. Fixes: 8bea869c5e56 ("ALSA: PCM midlevel: improve fifo_size handling") Signed-off-by: Clemens Ladisch Signed-off-by: Takashi Iwai Signed-off-by: Zefan Li commit 8fcf8e698c8f33ff9f94ad067121e77a9ead6be5 Author: David Dueck Date: Wed Sep 17 14:26:48 2014 +0200 can: at91_can: add missing prepare and unprepare of the clock commit e77980e50bc2850599d4d9c0192b67a9ffd6daac upstream. In order to make the driver work with the common clock framework, this patch converts the clk_enable()/clk_disable() to clk_prepare_enable()/clk_disable_unprepare(). While there, add the missing error handling. Signed-off-by: David Dueck Signed-off-by: Anthony Harivel Acked-by: Boris Brezillon Signed-off-by: Marc Kleine-Budde Signed-off-by: Zefan Li commit a125f73de40225692d7f0e722d452aad65467b8f Author: Marc Kleine-Budde Date: Tue Sep 16 15:31:27 2014 +0200 can: flexcan: put TX mailbox into TX_INACTIVE mode after tx-complete commit de5944883ebbedbf5adc8497659772f5da7b7d72 upstream. After sending a RTR frame the TX mailbox becomes a RX_EMPTY mailbox. To avoid side effects when the RX-FIFO is full, this patch puts the TX mailbox into TX_INACTIVE mode in the transmission complete interrupt handler. This, of course, leaves a race window between the actual completion of the transmission and the handling of tx-complete interrupt. However this is the best we can do without busy polling the tx complete interrupt. Signed-off-by: Marc Kleine-Budde [lizf: Backported to 3.4: adjust context] Signed-off-by: Zefan Li commit a6cdbaecaa2575bd2f0dd290ff83cfe2dae06959 Author: David Jander Date: Wed Sep 3 16:47:22 2014 +0200 can: flexcan: implement workaround for errata ERR005829 commit 25e924450fcb23c11c07c95ea8964dd9f174652e upstream. This patch implements the workaround mentioned in ERR005829: ERR005829: FlexCAN: FlexCAN does not transmit a message that is enabled to be transmitted in a specific moment during the arbitration process. Workaround: The workaround consists of two extra steps after setting up a message for transmission: Step 8: Reserve the first valid mailbox as an inactive mailbox (CODE=0b1000). If RX FIFO is disabled, this mailbox must be message buffer 0. Otherwise, the first valid mailbox can be found using the "RX FIFO filters" table in the FlexCAN chapter of the chip reference manual. Step 9: Write twice INACTIVE code (0b1000) into the first valid mailbox. Signed-off-by: David Jander Signed-off-by: Marc Kleine-Budde Signed-off-by: Zefan Li commit 12c6d3d6558aecc71f612698d2d18425f810e66d Author: David Jander Date: Wed Aug 27 11:58:05 2014 +0200 can: flexcan: correctly initialize mailboxes commit fc05b884a31dbf259cc73cc856e634ec3acbebb6 upstream. Apparently mailboxes may contain random data at startup, causing some of them being prepared for message reception. This causes overruns being missed or even confusing the IRQ check for trasmitted messages, increasing the transmit counter instead of the error counter. This patch initializes all mailboxes after the FIFO as RX_INACTIVE. Signed-off-by: David Jander Signed-off-by: Marc Kleine-Budde Signed-off-by: Zefan Li commit b06c98e5ba07bcadc0e18a1bc45cfd147da02b34 Author: Marc Kleine-Budde Date: Tue Sep 16 12:39:28 2014 +0200 can: flexcan: mark TX mailbox as TX_INACTIVE commit c32fe4ad3e4861b2bfa1f44114c564935a123dda upstream. This patch fixes the initialization of the TX mailbox. It is now correctly initialized as TX_INACTIVE not RX_EMPTY. Signed-off-by: Marc Kleine-Budde Signed-off-by: Zefan Li commit c228332adb106bd3cd2cfd99ae4e6a95eb51ccd9 Author: Mark Date: Wed Sep 17 19:15:43 2014 +0100 USB: storage: Add quirks for Entrega/Xircom USB to SCSI converters commit c80b4495c61636edc58fe1ce300f09f24db28e10 upstream. This patch adds quirks for Entrega Technologies (later Xircom PortGear) USB- SCSI converters. They use Shuttle Technology EUSB-01/EUSB-S1 chips. The US_FL_SCM_MULT_TARG quirk is needed to allow multiple devices on the SCSI chain to be accessed. Without it only the (single) device with SCSI ID 0 can be used. The standalone converter sold by Entrega had model number U1-SC25. Xircom acquired Entrega and re-branded the product line PortGear. The PortGear USB to SCSI Converter (model PGSCSI) is internally identical to the Entrega product, but later models may use a different USB ID. The Entrega-branded units have USB ID 1645:0007, as does my Xircom PGSCSI, but the Windows and Macintosh drivers also support 085A:0028. Entrega also sold the "Mac USB Dock", which provides two USB ports, a Mac (8-pin mini-DIN) serial port and a SCSI port. It appears to the computer as a four-port hub, USB-serial, and USB-SCSI converters. The USB-SCSI part may have initially used the same ID as the standalone U1-SC25 (1645:0007), but later production used 085A:0026. My Xircom PortGear PGSCSI has bcdDevice=0x0100. Units with bcdDevice=0x0133 probably also exist. This patch adds quirks for 1645:0007, 085A:0026 and 085A:0028. The Windows driver INF file also mentions 085A:0032 "PortStation SCSI Module", but I couldn't find any mention of that actually existing in the wild; perhaps it was cancelled before release? Signed-off-by: Mark Knibbs Signed-off-by: Greg Kroah-Hartman Signed-off-by: Zefan Li commit b75a0661cd875b9880aa61a9fe9a6ce873b5cf10 Author: Mark Date: Tue Sep 16 16:51:41 2014 +0100 USB: storage: Add quirk for Ariston Technologies iConnect USB to SCSI adapter commit b6a3ed677991558ce09046397a7c4d70530d15b3 upstream. Hi, The Ariston Technologies iConnect 025 and iConnect 050 (also known as e.g. iSCSI-50) are SCSI-USB converters which use Shuttle Technology/SCM Microsystems chips. Only the connectors differ; both have the same USB ID. The US_FL_SCM_MULT_TARG quirk is required to use SCSI devices with ID other than 0. I don't have one of these, but based on the other entries for Shuttle/ SCM-based converters this patch is very likely correct. I used 0x0000 and 0x9999 for bcdDeviceMin and bcdDeviceMax because I'm not sure which bcdDevice value the products use. Signed-off-by: Mark Knibbs Signed-off-by: Greg Kroah-Hartman Signed-off-by: Zefan Li commit 361be5431892472a729017528779293256e9c825 Author: Mark Date: Tue Sep 16 16:22:50 2014 +0100 USB: storage: Add quirk for Adaptec USBConnect 2000 USB-to-SCSI Adapter commit 67d365a57a51fb9dece6a5ceb504aa381cae1e5b upstream. The Adaptec USBConnect 2000 is another SCSI-USB converter which uses Shuttle Technology/SCM Microsystems chips. The US_FL_SCM_MULT_TARG quirk is required to use SCSI devices with ID other than 0. I don't have a USBConnect 2000, but based on the other entries for Shuttle/ SCM-based converters this patch is very likely correct. I used 0x0000 and 0x9999 for bcdDeviceMin and bcdDeviceMax because I'm not sure which bcdDevice value the product uses. Signed-off-by: Mark Knibbs Signed-off-by: Greg Kroah-Hartman Signed-off-by: Zefan Li commit b559f0bd22b56a1f753a77459b9fade3eebf5077 Author: Mike Christie Date: Wed Sep 3 00:00:39 2014 -0500 libiscsi: fix potential buffer overrun in __iscsi_conn_send_pdu commit db9bfd64b14a3a8f1868d2164518fdeab1b26ad1 upstream. This patches fixes a potential buffer overrun in __iscsi_conn_send_pdu. This function is used by iscsi drivers and userspace to send iscsi PDUs/ commands. For login commands, we have a set buffer size. For all other commands we do not support data buffers. This was reported by Dan Carpenter here: http://www.spinics.net/lists/linux-scsi/msg66838.html Reported-by: Dan Carpenter Signed-off-by: Mike Christie Reviewed-by: Sagi Grimberg Signed-off-by: Christoph Hellwig Signed-off-by: James Bottomley Signed-off-by: Zefan Li commit b6cab216d3bf0b0f302a229a28037a088c7ada01 Author: Trond Myklebust Date: Thu Sep 18 11:51:32 2014 -0400 NFSv4: Fix another bug in the close/open_downgrade code commit cd9288ffaea4359d5cfe2b8d264911506aed26a4 upstream. James Drew reports another bug whereby the NFS client is now sending an OPEN_DOWNGRADE in a situation where it should really have sent a CLOSE: the client is opening the file for O_RDWR, but then trying to do a downgrade to O_RDONLY, which is not allowed by the NFSv4 spec. Reported-by: James Drews Link: http://lkml.kernel.org/r/541AD7E5.8020409@engr.wisc.edu Fixes: aee7af356e15 (NFSv4: Fix problems with close in the presence...) Signed-off-by: Trond Myklebust [lizf: Backported to 3.4: adjust context] Signed-off-by: Zefan Li commit 0965d12e7ee793a911fed1b674ba3464680b959a Author: Joern Engel Date: Tue Sep 2 17:49:54 2014 -0400 iscsi-target: avoid NULL pointer in iscsi_copy_param_list failure commit 8ae757d09c45102b347a1bc2867f54ffc1ab8fda upstream. In iscsi_copy_param_list() a failed iscsi_param_list memory allocation currently invokes iscsi_release_param_list() to cleanup, and will promptly trigger a NULL pointer dereference. Instead, go ahead and return for the first iscsi_copy_param_list() failure case. Found by coverity. Signed-off-by: Joern Engel Signed-off-by: Nicholas Bellinger Signed-off-by: Zefan Li commit bce95d5d5ce5d57e72da6ab6dda819c4d79cbb52 Author: Nicholas Bellinger Date: Wed Sep 17 11:45:17 2014 -0700 iscsi-target: Fix memory corruption in iscsit_logout_post_handler_diffcid commit b53b0d99d6fbf7d44330395349a895521cfdbc96 upstream. This patch fixes a bug in iscsit_logout_post_handler_diffcid() where a pointer used as storage for list_for_each_entry() was incorrectly being used to determine if no matching entry had been found. This patch changes iscsit_logout_post_handler_diffcid() to key off bool conn_found to determine if the function needs to exit early. Reported-by: Joern Engel Signed-off-by: Nicholas Bellinger Signed-off-by: Zefan Li commit c0efaae65f73e201a2a06f9eb407e2a442279a78 Author: Hans de Goede Date: Thu Sep 11 10:10:26 2014 -0700 Input: i8042 - add nomux quirk for Avatar AVIU-145A6 commit d2682118f4bb3ceb835f91c1a694407a31bb7378 upstream. The sys_vendor / product_name are somewhat generic unfortunately, so this may lead to some false positives. But nomux usually does no harm, where as not having it clearly is causing problems on the Avatar AVIU-145A6. https://bugzilla.kernel.org/show_bug.cgi?id=77391 Reported-by: Hugo P Signed-off-by: Hans de Goede Signed-off-by: Dmitry Torokhov Signed-off-by: Zefan Li commit a98e6a5c58582fef294c97dd5a952ca8f1a5c720 Author: Hans de Goede Date: Wed Sep 10 13:53:37 2014 -0700 Input: i8042 - add Fujitsu U574 to no_timeout dmi table commit cc18a69c92d0972bc2fc5a047ee3be1e8398171b upstream. https://bugzilla.kernel.org/show_bug.cgi?id=69731 Reported-by: Jason Robinson Signed-off-by: Hans de Goede Signed-off-by: Dmitry Torokhov Signed-off-by: Zefan Li commit 87fd5ce262733a437d0135741c6621f5418e6ede Author: Charles Keepax Date: Tue Sep 9 16:51:49 2014 +0100 ASoC: samsung-i2s: Check secondary DAI exists before referencing commit 133c2681c4a0c1b589d138c2fdd0f131bdce20ed upstream. In a couple of places the driver is missing a check to ensure there is a secondary DAI before it de-references the pointer to it, causing a null pointer de-reference. This patch adds a check to avoid this. Signed-off-by: Charles Keepax Acked-by: Sylwester Nawrocki Signed-off-by: Mark Brown [lizf: Backported to 3.4: drop the changes to i2s_shutdown()] Signed-off-by: Zefan Li commit 1f8f277312d81d9412ec94bec8ab1ba0dce0bf05 Author: Cong Wang Date: Tue Sep 2 15:27:20 2014 -0700 perf: Fix a race condition in perf_remove_from_context() commit 3577af70a2ce4853d58e57d832e687d739281479 upstream. We saw a kernel soft lockup in perf_remove_from_context(), it looks like the `perf` process, when exiting, could not go out of the retry loop. Meanwhile, the target process was forking a child. So either the target process should execute the smp function call to deactive the event (if it was running) or it should do a context switch which deactives the event. It seems we optimize out a context switch in perf_event_context_sched_out(), and what's more important, we still test an obsolete task pointer when retrying, so no one actually would deactive that event in this situation. Fix it directly by reloading the task pointer in perf_remove_from_context(). This should cure the above soft lockup. Signed-off-by: Cong Wang Signed-off-by: Cong Wang Signed-off-by: Peter Zijlstra Cc: Paul Mackerras Cc: Arnaldo Carvalho de Melo Cc: Linus Torvalds Link: http://lkml.kernel.org/r/1409696840-843-1-git-send-email-xiyou.wangcong@gmail.com Signed-off-by: Ingo Molnar Signed-off-by: Zefan Li commit cf33e82d6b78b8ada9ee06809440a62adcb16021 Author: Aurelien Jarno Date: Sun Jul 20 19:58:23 2014 +0200 MIPS: ZBOOT: add missing include commit 29593fd5a8149462ed6fad0d522234facdaee6c8 upstream. Commit dc4d7b37 (MIPS: ZBOOT: gather string functions into string.c) moved the string related functions into a separate file, which might cause the following build error, depending on the configuration: | CC arch/mips/boot/compressed/decompress.o | In file included from linux/arch/mips/boot/compressed/../../../../lib/decompress_unxz.c:234:0, | from linux/arch/mips/boot/compressed/decompress.c:67: | linux/arch/mips/boot/compressed/../../../../lib/xz/xz_dec_stream.c: In function 'fill_temp': | linux/arch/mips/boot/compressed/../../../../lib/xz/xz_dec_stream.c:162:2: error: implicit declaration of function 'memcpy' [-Werror=implicit-function-declaration] | cc1: some warnings being treated as errors | linux/scripts/Makefile.build:308: recipe for target 'arch/mips/boot/compressed/decompress.o' failed | make[6]: *** [arch/mips/boot/compressed/decompress.o] Error 1 | linux/arch/mips/Makefile:308: recipe for target 'vmlinuz' failed It does not fail with the standard configuration, as when CONFIG_DYNAMIC_DEBUG is not enabled gets included in include/linux/dynamic_debug.h. There might be other ways for it to get indirectly included. We can't add the include directly in xz_dec_stream.c as some architectures might want to use a different version for the boot/ directory (see for example arch/x86/boot/string.h). Signed-off-by: Aurelien Jarno Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/7420/ Signed-off-by: Ralf Baechle Signed-off-by: Zefan Li commit 49d4f0197912461fb2939ca51521b47655b04b11 Author: Andrew Hunter Date: Thu Sep 4 14:17:16 2014 -0700 jiffies: Fix timeval conversion to jiffies commit d78c9300c51d6ceed9f6d078d4e9366f259de28c upstream. timeval_to_jiffies tried to round a timeval up to an integral number of jiffies, but the logic for doing so was incorrect: intervals corresponding to exactly N jiffies would become N+1. This manifested itself particularly repeatedly stopping/starting an itimer: setitimer(ITIMER_PROF, &val, NULL); setitimer(ITIMER_PROF, NULL, &val); would add a full tick to val, _even if it was exactly representable in terms of jiffies_ (say, the result of a previous rounding.) Doing this repeatedly would cause unbounded growth in val. So fix the math. Here's what was wrong with the conversion: we essentially computed (eliding seconds) jiffies = usec * (NSEC_PER_USEC/TICK_NSEC) by using scaling arithmetic, which took the best approximation of NSEC_PER_USEC/TICK_NSEC with denominator of 2^USEC_JIFFIE_SC = x/(2^USEC_JIFFIE_SC), and computed: jiffies = (usec * x) >> USEC_JIFFIE_SC and rounded this calculation up in the intermediate form (since we can't necessarily exactly represent TICK_NSEC in usec.) But the scaling arithmetic is a (very slight) *over*approximation of the true value; that is, instead of dividing by (1 usec/ 1 jiffie), we effectively divided by (1 usec/1 jiffie)-epsilon (rounding down). This would normally be fine, but we want to round timeouts up, and we did so by adding 2^USEC_JIFFIE_SC - 1 before the shift; this would be fine if our division was exact, but dividing this by the slightly smaller factor was equivalent to adding just _over_ 1 to the final result (instead of just _under_ 1, as desired.) In particular, with HZ=1000, we consistently computed that 10000 usec was 11 jiffies; the same was true for any exact multiple of TICK_NSEC. We could possibly still round in the intermediate form, adding something less than 2^USEC_JIFFIE_SC - 1, but easier still is to convert usec->nsec, round in nanoseconds, and then convert using time*spec*_to_jiffies. This adds one constant multiplication, and is not observably slower in microbenchmarks on recent x86 hardware. Tested: the following program: int main() { struct itimerval zero = {{0, 0}, {0, 0}}; /* Initially set to 10 ms. */ struct itimerval initial = zero; initial.it_interval.tv_usec = 10000; setitimer(ITIMER_PROF, &initial, NULL); /* Save and restore several times. */ for (size_t i = 0; i < 10; ++i) { struct itimerval prev; setitimer(ITIMER_PROF, &zero, &prev); /* on old kernels, this goes up by TICK_USEC every iteration */ printf("previous value: %ld %ld %ld %ld\n", prev.it_interval.tv_sec, prev.it_interval.tv_usec, prev.it_value.tv_sec, prev.it_value.tv_usec); setitimer(ITIMER_PROF, &prev, NULL); } return 0; } Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Paul Turner Cc: Richard Cochran Cc: Prarit Bhargava Reviewed-by: Paul Turner Reported-by: Aaron Jacobs Signed-off-by: Andrew Hunter [jstultz: Tweaked to apply to 3.17-rc] Signed-off-by: John Stultz [lizf: Backported to 3.4: adjust filename] Signed-off-by: Zefan Li commit a90ec2a8bbd22a90dfdb5ca1b294c900226b7ff8 Author: Al Viro Date: Sat Sep 13 21:55:46 2014 -0400 don't bugger nd->seq on set_root_rcu() from follow_dotdot_rcu() commit 7bd88377d482e1eae3c5329b12e33cfd664fa6a9 upstream. return the value instead, and have path_init() do the assignment. Broken by "vfs: Fix absolute RCU path walk failures due to uninitialized seq number", which was Cc-stable with 2.6.38+ as destination. This one should go where it went. To avoid dummy value returned in case when root is already set (it would do no harm, actually, since the only caller that doesn't ignore the return value is guaranteed to have nd->root *not* set, but it's more obvious that way), lift the check into callers. And do the same to set_root(), to keep them in sync. Signed-off-by: Al Viro [lizf: Backported to 3.4: - remove the changes to follow_link() as it doesn't call set_root()] Signed-off-by: Zefan Li commit e06503426ebc296f1ae67bfd4733afadb69076cb Author: Richard Larocque Date: Tue Sep 9 18:31:05 2014 -0700 alarmtimer: Lock k_itimer during timer callback commit 474e941bed9262f5fa2394f9a4a67e24499e5926 upstream. Locks the k_itimer's it_lock member when handling the alarm timer's expiry callback. The regular posix timers defined in posix-timers.c have this lock held during timout processing because their callbacks are routed through posix_timer_fn(). The alarm timers follow a different path, so they ought to grab the lock somewhere else. Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Richard Cochran Cc: Prarit Bhargava Cc: Sharvil Nanavati Signed-off-by: Richard Larocque Signed-off-by: John Stultz Signed-off-by: Zefan Li commit b114657d1e55a0484bcfdb3f3b946f96bb2f80e7 Author: Richard Larocque Date: Tue Sep 9 18:31:04 2014 -0700 alarmtimer: Do not signal SIGEV_NONE timers commit 265b81d23a46c39df0a735a3af4238954b41a4c2 upstream. Avoids sending a signal to alarm timers created with sigev_notify set to SIGEV_NONE by checking for that special case in the timeout callback. The regular posix timers avoid sending signals to SIGEV_NONE timers by not scheduling any callbacks for them in the first place. Although it would be possible to do something similar for alarm timers, it's simpler to handle this as a special case in the timeout. Prior to this patch, the alarm timer would ignore the sigev_notify value and try to deliver signals to the process anyway. Even worse, the sanity check for the value of sigev_signo is skipped when SIGEV_NONE was specified, so the signal number could be bogus. If sigev_signo was an unitialized value (as it often would be if SIGEV_NONE is used), then it's hard to predict which signal will be sent. Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Richard Cochran Cc: Prarit Bhargava Cc: Sharvil Nanavati Signed-off-by: Richard Larocque Signed-off-by: John Stultz Signed-off-by: Zefan Li commit 7ccf24be49f1020e408ee27a3714d41590009422 Author: Richard Larocque Date: Tue Sep 9 18:31:03 2014 -0700 alarmtimer: Return relative times in timer_gettime commit e86fea764991e00a03ff1e56409ec9cacdbda4c9 upstream. Returns the time remaining for an alarm timer, rather than the time at which it is scheduled to expire. If the timer has already expired or it is not currently scheduled, the it_value's members are set to zero. This new behavior matches that of the other posix-timers and the POSIX specifications. This is a change in user-visible behavior, and may break existing applications. Hopefully, few users rely on the old incorrect behavior. Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Richard Cochran Cc: Prarit Bhargava Cc: Sharvil Nanavati Signed-off-by: Richard Larocque [jstultz: minor style tweak] Signed-off-by: John Stultz [lizf: Backported to 3.4: - add alarm_expires_remaining() introduced by commit 6cffe00f7d4e] Signed-off-by: Zefan Li commit 40ee8d0faf83eb55d4829796a28dacf48519caec Author: Thomas Gleixner Date: Thu Sep 11 23:44:35 2014 +0200 futex: Unlock hb->lock in futex_wait_requeue_pi() error path commit 13c42c2f43b19aab3195f2d357db00d1e885eaa8 upstream. futex_wait_requeue_pi() calls futex_wait_setup(). If futex_wait_setup() succeeds it returns with hb->lock held and preemption disabled. Now the sanity check after this does: if (match_futex(&q.key, &key2)) { ret = -EINVAL; goto out_put_keys; } which releases the keys but does not release hb->lock. So we happily return to user space with hb->lock held and therefor preemption disabled. Unlock hb->lock before taking the exit route. Reported-by: Dave "Trinity" Jones Signed-off-by: Thomas Gleixner Reviewed-by: Darren Hart Reviewed-by: Davidlohr Bueso Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/alpine.DEB.2.10.1409112318500.4178@nanos Signed-off-by: Thomas Gleixner [lizf: Backported to 3.4: queue_unlock() takes two parameters] Signed-off-by: Zefan Li commit e393942b1628770467481935738fd214566fe7bb Author: Mathias Nyman Date: Thu Sep 11 13:55:48 2014 +0300 xhci: Fix null pointer dereference if xhci initialization fails commit c207e7c50f31113c24a9f536fcab1e8a256985d7 upstream. If xhci initialization fails before the roothub bandwidth domains (xhci->rh_bw[i]) are allocated it will oops when trying to access rh_bw members in xhci_mem_cleanup(). Reported-by: Manuel Reimer Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Zefan Li commit e887b00b542e4b35e37ccedd4bcd72c293358b8f Author: Mark Date: Thu Sep 11 13:15:45 2014 +0100 storage: Add single-LUN quirk for Jaz USB Adapter commit c66f1c62e85927357e7b3f4c701614dcb5c498a2 upstream. The Iomega Jaz USB Adapter is a SCSI-USB converter cable. The hardware seems to be identical to e.g. the Microtech XpressSCSI, using a Shuttle/ SCM chip set. However its firmware restricts it to only work with Jaz drives. On connecting the cable a message like this appears four times in the log: reset full speed USB device number 4 using uhci_hcd That's non-fatal but the US_FL_SINGLE_LUN quirk fixes it. Signed-off-by: Mark Knibbs Signed-off-by: Greg Kroah-Hartman Signed-off-by: Zefan Li commit 7decb190e8fc2b655586934431b4b61723998e47 Author: Joe Lawrence Date: Wed Sep 10 15:07:50 2014 -0400 usb: hub: take hub->hdev reference when processing from eventlist commit c605f3cdff53a743f6d875b76956b239deca1272 upstream. During surprise device hotplug removal tests, it was observed that hub_events may try to call usb_lock_device on a device that has already been freed. Protect the usb_device by taking out a reference (under the hub_event_lock) when hub_events pulls it off the list, returning the reference after hub_events is finished using it. Signed-off-by: Joe Lawrence Suggested-by: David Bulkow for using kref Suggested-by: Alan Stern for placement Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman Signed-off-by: Zefan Li commit dd3d82185d61b31589d5d9d99dda3d1877d0241c Author: John Sung Date: Tue Sep 9 10:06:51 2014 -0700 Input: serport - add compat handling for SPIOCSTYPE ioctl commit a80d8b02751060a178bb1f7a6b7a93645a7a308b upstream. When running a 32-bit inputattach utility in a 64-bit system, there will be error code "inputattach: can't set device type". This is caused by the serport device driver not supporting compat_ioctl, so that SPIOCSTYPE ioctl fails. Signed-off-by: John Sung Signed-off-by: Dmitry Torokhov Signed-off-by: Zefan Li commit 3ffeeae6961bdfe56d685d3681319cf76b67c449 Author: Ilya Dryomov Date: Tue Sep 9 19:39:15 2014 +0400 libceph: do not hard code max auth ticket len commit c27a3e4d667fdcad3db7b104f75659478e0c68d8 upstream. We hard code cephx auth ticket buffer size to 256 bytes. This isn't enough for any moderate setups and, in case tickets themselves are not encrypted, leads to buffer overflows (ceph_x_decrypt() errors out, but ceph_decode_copy() doesn't - it's just a memcpy() wrapper). Since the buffer is allocated dynamically anyway, allocated it a bit later, at the point where we know how much is going to be needed. Fixes: http://tracker.ceph.com/issues/8979 Signed-off-by: Ilya Dryomov Reviewed-by: Sage Weil Signed-off-by: Zefan Li commit 54bf0ca8b15b687cfd932777a3894731c08d79a2 Author: Ilya Dryomov Date: Mon Sep 8 17:25:34 2014 +0400 libceph: add process_one_ticket() helper commit 597cda357716a3cf8d994cb11927af917c8d71fa upstream. Add a helper for processing individual cephx auth tickets. Needed for the next commit, which deals with allocating ticket buffers. (Most of the diff here is whitespace - view with git diff -b). Signed-off-by: Ilya Dryomov Reviewed-by: Sage Weil Signed-off-by: Zefan Li commit 36d5b7b83ab7931290de2ce533f75c540cb90702 Author: Sage Weil Date: Mon Aug 4 07:01:54 2014 -0700 libceph: gracefully handle large reply messages from the mon commit 73c3d4812b4c755efeca0140f606f83772a39ce4 upstream. We preallocate a few of the message types we get back from the mon. If we get a larger message than we are expecting, fall back to trying to allocate a new one instead of blindly using the one we have. Signed-off-by: Sage Weil Reviewed-by: Ilya Dryomov [lizf: Backported to 3.4: s/front_alloc_len/front_max/g] Signed-off-by: Zefan Li commit 386ba13164c2c136c0fbf585aa7b63831c96d7c8 Author: Dmitry Torokhov Date: Sat Aug 30 13:51:06 2014 -0700 Input: synaptics - add support for ForcePads commit 5715fc764f7753d464dbe094b5ef9cffa6e479a4 upstream. ForcePads are found on HP EliteBook 1040 laptops. They lack any kind of physical buttons, instead they generate primary button click when user presses somewhat hard on the surface of the touchpad. Unfortunately they also report primary button click whenever there are 2 or more contacts on the pad, messing up all multi-finger gestures (2-finger scrolling, multi-finger tapping, etc). To cope with this behavior we introduce a delay (currently 50 msecs) in reporting primary press in case more contacts appear. Reviewed-by: Hans de Goede Signed-off-by: Dmitry Torokhov Signed-off-by: Zefan Li commit 96eb53749fbfd77b92031cc6b97458fe5c4244ae Author: Thomas Pugliese Date: Thu Aug 7 15:45:35 2014 -0500 uwb: init beacon cache entry before registering uwb device commit 675f0ab2fe5a0f7325208e60b617a5f32b86d72c upstream. Make sure the uwb_dev->bce entry is set before calling uwb_dev_add in uwbd_dev_onair so that usermode will only see the device after it is properly initialized. This fixes a kernel panic that can occur if usermode tries to access the IEs sysfs attribute of a UWB device before the driver has had a chance to set the beacon cache entry. Signed-off-by: Thomas Pugliese Signed-off-by: Greg Kroah-Hartman [lizf: Backported to 3.4: adjust context] Signed-off-by: Zefan Li commit 0d69cbb4a932a244ed2d5344b6ef0ccdf99fc8a3 Author: Taylor Braun-Jones Date: Thu Aug 7 14:25:06 2014 -0400 USB: ftdi_sio: Add support for GE Healthcare Nemo Tracker device commit 9c491c372d677b6420e0f8c6361fe422791662cc upstream. Signed-off-by: Taylor Braun-Jones Cc: Johan Hovold Signed-off-by: Greg Kroah-Hartman [lizf: Backported to 3.4: adjust context] Signed-off-by: Zefan Li commit 32b45e0ec8c6d1b613e074adc13385d4c63769a4 Author: Hans de Goede Date: Mon Sep 8 14:39:52 2014 -0700 Input: elantech - fix detection of touchpad on ASUS s301l commit 271329b3c798b2102120f5df829071c211ef00ed upstream. Adjust Elantech signature validation to account fo rnewer models of touchpads. Reported-and-tested-by: Màrius Monton Signed-off-by: Hans de Goede Signed-off-by: Dmitry Torokhov Signed-off-by: Zefan Li commit 488d89601e77e23b18755a0563579b67d950d9fb Author: Felipe Balbi Date: Wed Aug 27 16:38:04 2014 -0500 usb: host: xhci: fix compliance mode workaround commit 96908589a8b2584b1185f834d365f5cc360e8226 upstream. Commit 71c731a (usb: host: xhci: Fix Compliance Mode on SN65LVP3502CP Hardware) implemented a workaround for a known issue with Texas Instruments' USB 3.0 redriver IC but it left a condition where any xHCI host would be taken out of reset if port was placed in compliance mode and there was no device connected to the port. That condition would trigger a fake connection to a non-existent device so that usbcore would trigger a warm reset of the port, thus taking the link out of reset. This has the side-effect of preventing any xHCI host connected to a Linux machine from starting and running the USB 3.0 Electrical Compliance Suite because the port will mysteriously taken out of compliance mode and, thus, xHCI won't step through the necessary compliance patterns for link validation. This patch fixes the issue by just adding a missing check for XHCI_COMP_MODE_QUIRK inside xhci_hub_report_usb3_link_state() when PORT_CAS isn't set. This patch should be backported to all kernels containing commit 71c731a. Fixes: 71c731a (usb: host: xhci: Fix Compliance Mode on SN65LVP3502CP Hardware) Cc: Alexis R. Cortes