commit e9b1a5ca4be235d1eef84c754f78f53b1ca1a242 Author: Ben Hutchings Date: Fri Jul 11 13:34:01 2014 +0100 Linux 3.2.61 commit 77c01a54cde87eb3bf6685fb44398352f11db3fa Author: Michael S. Tsirkin Date: Mon Mar 10 19:28:08 2014 +0200 skbuff: skb_segment: orphan frags before copying commit 1fd819ecb90cc9b822cd84d3056ddba315d3340f upstream. skb_segment copies frags around, so we need to copy them carefully to avoid accessing user memory after reporting completion to userspace through a callback. skb_segment doesn't normally happen on datapath: TSO needs to be disabled - so disabling zero copy in this case does not look like a big deal. Signed-off-by: Michael S. Tsirkin Acked-by: Herbert Xu Signed-off-by: David S. Miller [bwh: Backported to 3.2. As skb_segment() only supports page-frags *or* a frag list, there is no need for the additional frag_skb pointer or the preparatory renaming.] Signed-off-by: Ben Hutchings commit 3ee479fddc52bbcb3b215be56673e9784890b486 Author: Michael S. Tsirkin Date: Fri Jul 20 09:23:20 2012 +0000 skbuff: export skb_copy_ubufs commit dcc0fb782b3a6e2abfeaaeb45dd88ed09596be0f upstream. Export skb_copy_ubufs so that modules can orphan frags. Signed-off-by: Michael S. Tsirkin Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit dc4f7b1edb525ee356abc0f7ef96550dcd0a3d4c Author: Michael S. Tsirkin Date: Fri Jul 20 09:23:07 2012 +0000 skbuff: add an api to orphan frags commit a353e0ce0fd42d8859260666d1e9b10f2abd4698 upstream. Many places do if ((skb_shinfo(skb)->tx_flags & SKBTX_DEV_ZEROCOPY)) skb_copy_ubufs(skb, gfp_mask); to copy and invoke frag destructors if necessary. Add an inline helper for this. Signed-off-by: Michael S. Tsirkin Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit a0eb191eff753e790def174b3fbe66efadfd401d Author: Tejun Heo Date: Thu Jul 3 15:43:15 2014 -0400 ptrace,x86: force IRET path after a ptrace_stop() commit b9cd18de4db3c9ffa7e17b0dc0ca99ed5aa4d43a upstream. The 'sysret' fastpath does not correctly restore even all regular registers, much less any segment registers or reflags values. That is very much part of why it's faster than 'iret'. Normally that isn't a problem, because the normal ptrace() interface catches the process using the signal handler infrastructure, which always returns with an iret. However, some paths can get caught using ptrace_event() instead of the signal path, and for those we need to make sure that we aren't going to return to user space using 'sysret'. Otherwise the modifications that may have been done to the register set by the tracer wouldn't necessarily take effect. Fix it by forcing IRET path by setting TIF_NOTIFY_RESUME from arch_ptrace_stop_needed() which is invoked from ptrace_stop(). Signed-off-by: Tejun Heo Reported-by: Andy Lutomirski Acked-by: Oleg Nesterov Suggested-by: Linus Torvalds Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit 5005abc1a94da6906af4b1e09d4472b94f1f9c66 Author: Geert Uytterhoeven Date: Mon Apr 14 18:52:14 2014 +0200 Documentation: Update stable address in Chinese and Japanese translations commit 98b0f811aade1b7c6e7806c86aa0befd5919d65f upstream. The English and Korean translations were updated, the Chinese and Japanese weren't. Signed-off-by: Geert Uytterhoeven Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 64bf838ef253a6c5b05530461f2aee94bbfecc5b Author: Liu Hua Date: Thu Mar 27 06:56:18 2014 +0100 ARM: 8012/1: kdump: Avoid overflow when converting pfn to physaddr commit 8fad87bca7ac9737e413ba5f1656f1114a8c314d upstream. When we configure CONFIG_ARM_LPAE=y, pfn << PAGE_SHIFT will overflow if pfn >= 0x100000 in copy_oldmem_page. So use __pfn_to_phys for converting. Signed-off-by: Liu Hua Signed-off-by: Russell King Signed-off-by: Ben Hutchings commit fac90e80d8e567113477de8f1ce91e2e3410ac57 Author: David Woodhouse Date: Mon Jun 9 14:09:53 2014 +0100 iommu/vt-d: Fix missing IOTLB flush in intel_iommu_unmap() Part of commit ea8ea460c9ace60bbb5ac6e5521d637d5c15293d upstream. This missing IOTLB flush was added as a minor, inconsequential bug-fix in commit ea8ea460c ("iommu/vt-d: Clean up and fix page table clear/free behaviour") in 3.15. It wasn't originally intended for -stable but a couple of users have reported issues which turn out to be fixed by adding the missing flush. Signed-off-by: David Woodhouse [bwh: Backported to 3.2: - Adjust context - Use &dmar_domain->iommu_bmp, as it is a single word not an array] Signed-off-by: Ben Hutchings commit 30c7c6dfd9c8a42aacd6d0d61d2209bc13abbfa3 Author: Ben Collins Date: Fri Sep 13 12:46:44 2013 -0400 megaraid: Use resource_size_t for PCI resources, not long commit 11f8a7b31f2140b0dc164bb484281235ffbe51d3 upstream. The assumption that sizeof(long) >= sizeof(resource_size_t) can lead to truncation of the PCI resource address, meaning this driver didn't work on 32-bit systems with 64-bit PCI adressing ranges. Signed-off-by: Ben Collins Acked-by: Sumit Saxena Signed-off-by: James Bottomley [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit c8d446a0623a08338ea07f45eed36569d8242485 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 [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit bbe9504c3a9f7cea3cd6d2660142d9b9bd5821f7 Author: Nicholas Bellinger Date: Mon Jun 16 20:59:52 2014 +0000 target: Explicitly clear ramdisk_mcp backend pages Part of commit 4442dc8a92b8f9ad8ee9e7f8438f4c04c03a22dc upstream. This patch changes rd_allocate_sgl_table() to explicitly clear ramdisk_mcp backend memory pages by passing __GFP_ZERO into alloc_pages(). This addresses a potential security issue where reading from a ramdisk_mcp could return sensitive information, and follows what >= v3.15 does to explicitly clear ramdisk_mcp memory at backend device initialization time. Reported-by: Jorge Daniel Sequeira Matias Cc: Jorge Daniel Sequeira Matias Signed-off-by: Nicholas Bellinger Signed-off-by: Ben Hutchings commit 63eed2fa66568ef3c85530d0c1d14812907aa7fe Author: Wei Yang Date: Sun Jun 1 15:25:41 2014 +0800 net/mlx4_core: Preserve pci_dev_data after __mlx4_remove_one() [ Upstream commit befdf8978accecac2e0739e6b5075afc62db37fe ] This patch wrap up a helper function __mlx4_remove_one() which does the tear down function but preserve the drv_data. Functions like mlx4_pci_err_detected() and mlx4_restart_one() will call this one with out releasing drvdata. Signed-off-by: Wei Yang Signed-off-by: Ben Hutchings commit cce11ac1f254935cb9e3914ac36ad0e3fe4c0767 Author: Wei Yang Date: Sun Jun 1 15:25:40 2014 +0800 mlx4_core: Stash PCI ID driver_data in mlx4_priv structure [ No upstream commit, this is a cherry picked backport enabler. ] That way we can check flags later on, when we've finished with the pci_device_id structure. This is a backport. Signed-off-by: Roland Dreier Signed-off-by: Ben Hutchings commit fe33a3ee987dac85ac24b2d8147d2165051c80d9 Author: Xufeng Zhang Date: Thu Jun 12 10:53:36 2014 +0800 sctp: Fix sk_ack_backlog wrap-around problem [ Upstream commit d3217b15a19a4779c39b212358a5c71d725822ee ] Consider the scenario: For a TCP-style socket, while processing the COOKIE_ECHO chunk in sctp_sf_do_5_1D_ce(), after it has passed a series of sanity check, a new association would be created in sctp_unpack_cookie(), but afterwards, some processing maybe failed, and sctp_association_free() will be called to free the previously allocated association, in sctp_association_free(), sk_ack_backlog value is decremented for this socket, since the initial value for sk_ack_backlog is 0, after the decrement, it will be 65535, a wrap-around problem happens, and if we want to establish new associations afterward in the same socket, ABORT would be triggered since sctp deem the accept queue as full. Fix this issue by only decrementing sk_ack_backlog for associations in the endpoint's list. Fix-suggested-by: Neil Horman Signed-off-by: Xufeng Zhang Acked-by: Daniel Borkmann Acked-by: Vlad Yasevich Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit bd89ed9b75277f5a16f91a2331539dd34a8cf852 Author: Eric Dumazet Date: Thu May 29 08:45:14 2014 -0700 net: fix inet_getid() and ipv6_select_ident() bugs [ Upstream commit 39c36094d78c39e038c1e499b2364e13bce36f54 ] I noticed we were sending wrong IPv4 ID in TCP flows when MTU discovery is disabled. Note how GSO/TSO packets do not have monotonically incrementing ID. 06:37:41.575531 IP (id 14227, proto: TCP (6), length: 4396) 06:37:41.575534 IP (id 14272, proto: TCP (6), length: 65212) 06:37:41.575544 IP (id 14312, proto: TCP (6), length: 57972) 06:37:41.575678 IP (id 14317, proto: TCP (6), length: 7292) 06:37:41.575683 IP (id 14361, proto: TCP (6), length: 63764) It appears I introduced this bug in linux-3.1. inet_getid() must return the old value of peer->ip_id_count, not the new one. Lets revert this part, and remove the prevention of a null identification field in IPv6 Fragment Extension Header, which is dubious and not even done properly. Fixes: 87c48fa3b463 ("ipv6: make fragment identifications less predictable") Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 30080eb2ea49bff4101b0a3587ae26a590b32c54 Author: Tom Gundersen Date: Thu May 15 23:21:30 2014 +0200 net: tunnels - enable module autoloading [ Upstream commit f98f89a0104454f35a62d681683c844f6dbf4043 ] Enable the module alias hookup to allow tunnel modules to be autoloaded on demand. This is in line with how most other netdev kinds work, and will allow userspace to create tunnels without having CAP_SYS_MODULE. Signed-off-by: Tom Gundersen Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 7343f010459a76c02ab4868a7301ae998f451a37 Author: Michal Schmidt Date: Mon Jun 2 18:25:02 2014 +0200 netlink: rate-limit leftover bytes warning and print process name [ Upstream commit bfc5184b69cf9eeb286137640351c650c27f118a ] Any process is able to send netlink messages with leftover bytes. Make the warning rate-limited to prevent too much log spam. The warning is supposed to help find userspace bugs, so print the triggering command name to implicate the buggy program. [v2: Use pr_warn_ratelimited instead of printk_ratelimited.] Signed-off-by: Michal Schmidt Signed-off-by: David S. Miller [bwh: Add #include of for definition of struct task_struct, as in 3.2 it doesn't get included indirectly on all architectures. Thanks to Guenter Roeck for debugging this.] Signed-off-by: Ben Hutchings commit f50bf61a3282988b2fe46e8cb88c9b8698a2d8d2 Author: Markos Chandras Date: Wed Jan 22 14:40:00 2014 +0000 MIPS: asm: thread_info: Add _TIF_SECCOMP flag commit 137f7df8cead00688524c82360930845396b8a21 upstream. Add _TIF_SECCOMP flag to _TIF_WORK_SYSCALL_ENTRY to indicate that the system call needs to be checked against a seccomp filter. Signed-off-by: Markos Chandras Reviewed-by: Paul Burton Reviewed-by: James Hogan Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/6405/ Signed-off-by: Ralf Baechle [bwh: Backported to 3.2: various other flags are not included in _TIF_WORK_SYSCALL_ENTRY] Signed-off-by: Ben Hutchings commit 70c8d44f427d735d2f813559444713d6bfaed1ab Author: Ralf Baechle Date: Wed May 29 01:02:18 2013 +0200 MIPS: Cleanup flags in syscall flags handlers. commit e7f3b48af7be9f8007a224663a5b91340626fed5 upstream. This will simplify further modifications. Signed-off-by: Ralf Baechle Signed-off-by: Ben Hutchings commit 09b0c6269f9683d39d43e4ba0c1cfdcd04f40c11 Author: Peter Zijlstra Date: Fri May 2 16:56:01 2014 +0200 perf: Fix race in removing an event commit 46ce0fe97a6be7532ce6126bb26ce89fed81528c upstream. When removing a (sibling) event we do: raw_spin_lock_irq(&ctx->lock); perf_group_detach(event); raw_spin_unlock_irq(&ctx->lock); perf_remove_from_context(event); raw_spin_lock_irq(&ctx->lock); ... raw_spin_unlock_irq(&ctx->lock); Now, assuming the event is a sibling, it will be 'unreachable' for things like ctx_sched_out() because that iterates the groups->siblings, and we just unhooked the sibling. So, if during we get ctx_sched_out(), it will miss the event and not call event_sched_out() on it, leaving it programmed on the PMU. The subsequent perf_remove_from_context() call will find the ctx is inactive and only call list_del_event() to remove the event from all other lists. Hereafter we can proceed to free the event; while still programmed! Close this hole by moving perf_group_detach() inside the same ctx->lock region(s) perf_remove_from_context() has. The condition on inherited events only in __perf_event_exit_task() is likely complete crap because non-inherited events are part of groups too and we're tearing down just the same. But leave that for another patch. Most-likely-Fixes: e03a9a55b4e ("perf: Change close() semantics for group events") Reported-by: Vince Weaver Tested-by: Vince Weaver Much-staring-at-traces-by: Vince Weaver Much-staring-at-traces-by: Thomas Gleixner Cc: Arnaldo Carvalho de Melo Cc: Linus Torvalds Signed-off-by: Peter Zijlstra Link: http://lkml.kernel.org/r/20140505093124.GN17778@laptop.programming.kicks-ass.net Signed-off-by: Ingo Molnar [bwh: Backported to 3.2: drop change in perf_pmu_migrate_context()] Signed-off-by: Ben Hutchings commit f935bf46b0748d78d5d8c9725312aee3443f19d0 Author: James Bottomley Date: Tue Jan 21 07:01:41 2014 -0800 dual scan thread bug fix commit f2495e228fce9f9cec84367547813cbb0d6db15a upstream. In the highly unusual case where two threads are running concurrently through the scanning code scanning the same target, we run into the situation where one may allocate the target while the other is still using it. In this case, because the reap checks for STARGET_CREATED and kills the target without reference counting, the second thread will do the wrong thing on reap. Fix this by reference counting even creates and doing the STARGET_CREATED check in the final put. Tested-by: Sarah Sharp Signed-off-by: James Bottomley Signed-off-by: Ben Hutchings commit 181086c6cc8a186f26bbb87872e48bb7973fdc28 Author: James Bottomley Date: Tue Jan 21 07:00:50 2014 -0800 fix our current target reap infrastructure commit e63ed0d7a98014fdfc2cfeb3f6dada313dcabb59 upstream. This patch eliminates the reap_ref and replaces it with a proper kref. On last put of this kref, the target is removed from visibility in sysfs. The final call to scsi_target_reap() for the device is done from __scsi_remove_device() and only if the device was made visible. This ensures that the target disappears as soon as the last device is gone rather than waiting until final release of the device (which is often too long). Reviewed-by: Alan Stern Tested-by: Sarah Sharp Signed-off-by: James Bottomley Signed-off-by: Ben Hutchings commit b5a10549d528827aa331c1d95a6170032718babe Author: Bart Van Assche Date: Fri Jun 29 15:36:07 2012 +0000 Stop accepting SCSI requests before removing a device commit b485462aca7df4e32bcf7efb6f84a69e8b640243 upstream. Avoid that the code for requeueing SCSI requests triggers a crash by making sure that that code isn't scheduled anymore after a device has been removed. Also, source code inspection of __scsi_remove_device() revealed a race condition in this function: no new SCSI requests must be accepted for a SCSI device after device removal started. Signed-off-by: Bart Van Assche Reviewed-by: Mike Christie Acked-by: Tejun Heo Signed-off-by: James Bottomley [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 3f5ec1a1dc36df4e56656e21ad4a02048bc101b9 Author: Nicholas Bellinger Date: Mon Jun 16 20:25:54 2014 +0000 target: Fix left-over se_lun->lun_sep pointer OOPs commit 83ff42fcce070801a3aa1cd6a3269d7426271a8d upstream. This patch fixes a left-over se_lun->lun_sep pointer OOPs when one of the /sys/kernel/config/target/$FABRIC/$WWPN/$TPGT/lun/$LUN/alua* attributes is accessed after the $DEVICE symlink has been removed. To address this bug, go ahead and clear se_lun->lun_sep memory in core_dev_unexport(), so that the existing checks for show/store ALUA attributes in target_core_fabric_configfs.c work as expected. Reported-by: Sebastian Herbszt Tested-by: Sebastian Herbszt Signed-off-by: Nicholas Bellinger [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 167dc42e69226e50b97b44f0777a387ab1a932cc Author: Markos Chandras Date: Mon Jun 23 09:48:51 2014 +0100 MIPS: MSC: Prevent out-of-bounds writes to MIPS SC ioremap'd region commit ab6c15bc6620ebe220970cc040b29bcb2757f373 upstream. Previously, the lower limit for the MIPS SC initialization loop was set incorrectly allowing one extra loop leading to writes beyond the MSC ioremap'd space. More precisely, the value of the 'imp' in the last loop increased beyond the msc_irqmap_t boundaries and as a result of which, the 'n' variable was loaded with an incorrect value. This value was used later on to calculate the offset in the MSC01_IC_SUP which led to random crashes like the following one: CPU 0 Unable to handle kernel paging request at virtual address e75c0200, epc == 8058dba4, ra == 8058db90 [...] Call Trace: [<8058dba4>] init_msc_irqs+0x104/0x154 [<8058b5bc>] arch_init_irq+0xd8/0x154 [<805897b0>] start_kernel+0x220/0x36c Kernel panic - not syncing: Attempted to kill the idle task! This patch fixes the problem Signed-off-by: Markos Chandras Reviewed-by: James Hogan Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/7118/ Signed-off-by: Ralf Baechle Signed-off-by: Ben Hutchings commit bdcdb4312cfd2f45bfc4887cc34dcc1956db48f4 Author: Alex Smith Date: Tue Jun 17 10:39:53 2014 +0100 recordmcount/MIPS: Fix possible incorrect mcount_loc table entries in modules commit 91ad11d7cc6f4472ebf177a6252fbf0fd100d798 upstream. On MIPS calls to _mcount in modules generate 2 instructions to load the _mcount address (and therefore 2 relocations). The mcount_loc table should only reference the first of these, so the second is filtered out by checking the relocation offset and ignoring ones that immediately follow the previous one seen. However if a module has an _mcount call at offset 0, the second relocation would not be filtered out due to old_r_offset == 0 being taken to mean that the current relocation is the first one seen, and both would end up in the mcount_loc table. This results in ftrace_make_nop() patching both (adjacent) instructions to branches over the _mcount call sequence like so: 0xffffffffc08a8000: 04 00 00 10 b 0xffffffffc08a8014 0xffffffffc08a8004: 04 00 00 10 b 0xffffffffc08a8018 0xffffffffc08a8008: 2d 08 e0 03 move at,ra ... The second branch is in the delay slot of the first, which is defined to be unpredictable - on the platform on which this bug was encountered, it triggers a reserved instruction exception. Fix by initializing old_r_offset to ~0 and using that instead of 0 to determine whether the current relocation is the first seen. Signed-off-by: Alex Smith Cc: linux-kernel@vger.kernel.org Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/7098/ Signed-off-by: Ralf Baechle Signed-off-by: Ben Hutchings commit 2c1ec4bfa383ddf85459a3c299db27377ac537d0 Author: Zhaowei Yuan Date: Wed Jun 18 14:33:59 2014 +0800 drm: fix NULL pointer access by wrong ioctl commit 1539fb9bd405ee32282ea0a38404f9e008ac5b7a upstream. If user uses wrong ioctl command with _IOC_NONE and argument size greater than 0, it can cause NULL pointer access from memset of line 463. If _IOC_NONE, don't memset to 0 for kdata. Signed-off-by: Zhaowei Yuan Reviewed-by: David Herrmann Signed-off-by: Dave Airlie [bwh: Backported to 3.2: adjust indentation] Signed-off-by: Ben Hutchings commit e0b2508d7d22cca58322a7d29f6339df0c01bf54 Author: Hugh Dickins Date: Mon Jun 23 13:22:07 2014 -0700 mm: fix crashes from mbind() merging vmas commit d05f0cdcbe6388723f1900c549b4850360545201 upstream. In v2.6.34 commit 9d8cebd4bcd7 ("mm: fix mbind vma merge problem") introduced vma merging to mbind(), but it should have also changed the convention of passing start vma from queue_pages_range() (formerly check_range()) to new_vma_page(): vma merging may have already freed that structure, resulting in BUG at mm/mempolicy.c:1738 and probably worse crashes. Fixes: 9d8cebd4bcd7 ("mm: fix mbind vma merge problem") Reported-by: Naoya Horiguchi Tested-by: Naoya Horiguchi Signed-off-by: Hugh Dickins Acked-by: Christoph Lameter Cc: KOSAKI Motohiro Cc: Minchan Kim Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds [bwh: Backported to 3.2: - Adjust context - Keep the same arguments to migrate_pages() except for private=start] Signed-off-by: Ben Hutchings commit 386292b433495a8dfc5c2991145943d97e559fff Author: Minchan Kim Date: Mon Oct 8 16:33:38 2012 -0700 mm: revert 0def08e3 ("mm/mempolicy.c: check return code of check_range") commit 082708072a4250f5c4dbc62065e7af93f5e45646 upstream. Revert commit 0def08e3acc2 because check_range can't fail in migrate_to_node with considering current usecases. Quote from Johannes : I think it makes sense to revert. Not because of the semantics, but I : just don't see how check_range() could even fail for this callsite: : : 1. we pass mm->mmap->vm_start in there, so we should not fail due to : find_vma() : : 2. we pass MPOL_MF_DISCONTIG_OK, so the discontig checks do not apply : and so can not fail : : 3. we pass MPOL_MF_MOVE | MPOL_MF_MOVE_ALL, the page table loops will : continue until addr == end, so we never fail with -EIO And I added a new VM_BUG_ON for checking migrate_to_node's future usecase which might pass to MPOL_MF_STRICT. Suggested-by: Johannes Weiner Signed-off-by: Minchan Kim Acked-by: KOSAKI Motohiro Cc: Mel Gorman Cc: Christoph Lameter Cc: David Rientjes Cc: Vasiliy Kulikov Acked-by: Johannes Weiner Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit de5f02d08d32aaf559f57def64176dae52a2e00a Author: Naoya Horiguchi Date: Mon Jun 23 13:22:03 2014 -0700 hugetlb: fix copy_hugetlb_page_range() to handle migration/hwpoisoned entry commit 4a705fef986231a3e7a6b1a6d3c37025f021f49f upstream. There's a race between fork() and hugepage migration, as a result we try to "dereference" a swap entry as a normal pte, causing kernel panic. The cause of the problem is that copy_hugetlb_page_range() can't handle "swap entry" family (migration entry and hwpoisoned entry) so let's fix it. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Naoya Horiguchi Acked-by: Hugh Dickins Cc: Christoph Lameter Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit bb99d6796995968ca6a42b17fbfb48d073bb234c Author: Andy Lutomirski Date: Mon Jun 23 14:22:15 2014 -0700 x86_32, entry: Do syscall exit work on badsys (CVE-2014-4508) commit 554086d85e71f30abe46fc014fea31929a7c6a8a upstream. The bad syscall nr paths are their own incomprehensible route through the entry control flow. Rearrange them to work just like syscalls that return -ENOSYS. This fixes an OOPS in the audit code when fast-path auditing is enabled and sysenter gets a bad syscall nr (CVE-2014-4508). This has probably been broken since Linux 2.6.27: af0575bba0 i386 syscall audit fast-path Cc: Roland McGrath Reported-by: Toralf Förster Signed-off-by: Andy Lutomirski Link: http://lkml.kernel.org/r/e09c499eade6fc321266dd6b54da7beb28d6991c.1403558229.git.luto@amacapital.net Signed-off-by: H. Peter Anvin [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit a8a2fdd030095e0dedb38c1c8dbbadb24ad89a6a Author: Greg Kroah-Hartman Date: Fri Jun 20 22:00:53 2014 -0700 lzo: properly check for overruns commit 206a81c18401c0cde6e579164f752c4b147324ce upstream. The lzo decompressor can, if given some really crazy data, possibly overrun some variable types. Modify the checking logic to properly detect overruns before they happen. Reported-by: "Don A. Bailey" Tested-by: "Don A. Bailey" Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 7d137504362a946bae295ff8cba7bbe50961a5e9 Author: Markus F.X.J. Oberhumer Date: Mon Aug 13 17:25:44 2012 +0200 lib/lzo: Update LZO compression to current upstream version commit 8b975bd3f9089f8ee5d7bbfd798537b992bbc7e7 upstream. This commit updates the kernel LZO code to the current upsteam version which features a significant speed improvement - benchmarking the Calgary and Silesia test corpora typically shows a doubled performance in both compression and decompression on modern i386/x86_64/powerpc machines. Signed-off-by: Markus F.X.J. Oberhumer Signed-off-by: Ben Hutchings commit d83ff0c1d743320709de6522eff9e814abb041e8 Author: Markus F.X.J. Oberhumer Date: Mon Aug 13 17:24:24 2012 +0200 lib/lzo: Rename lzo1x_decompress.c to lzo1x_decompress_safe.c commit b6bec26cea948148a9420e7a0ac337f925de49e7 upstream. Rename the source file to match the function name and thereby also make room for a possible future even slightly faster "non-safe" decompressor version. Signed-off-by: Markus F.X.J. Oberhumer Signed-off-by: Ben Hutchings commit cd58af052252f71479251d19605226cdb166899e Author: Oleg Nesterov Date: Sun Apr 13 20:58:54 2014 +0200 tracing: Fix syscall_*regfunc() vs copy_process() race commit 4af4206be2bd1933cae20c2b6fb2058dbc887f7c upstream. syscall_regfunc() and syscall_unregfunc() should set/clear TIF_SYSCALL_TRACEPOINT system-wide, but do_each_thread() can race with copy_process() and miss the new child which was not added to the process/thread lists yet. Change copy_process() to update the child's TIF_SYSCALL_TRACEPOINT under tasklist. Link: http://lkml.kernel.org/p/20140413185854.GB20668@redhat.com Fixes: a871bd33a6c0 "tracing: Add syscall tracepoints" Acked-by: Frederic Weisbecker Acked-by: Paul E. McKenney Signed-off-by: Oleg Nesterov Signed-off-by: Steven Rostedt Signed-off-by: Ben Hutchings commit e4d4e84fcb628436e36bedb5f75a852e13a5df75 Author: Rafał Miłecki Date: Thu Jun 12 22:28:22 2014 +0200 b43: fix frequency reported on G-PHY with /new/ firmware commit 2fc68eb122c7ea6cd5be1fe7d6650c0beb2f4f40 upstream. Support for firmware rev 508+ was added years ago, but we never noticed it reports channel in a different way for G-PHY devices. Instead of offset from 2400 MHz it simply passes channel id (AKA hw_value). So far it was (most probably) affecting monitor mode users only, but the following recent commit made it noticeable for quite everybody: commit 3afc2167f60a327a2c1e1e2600ef209a3c2b75b7 Author: Emmanuel Grumbach Date: Tue Mar 4 16:50:13 2014 +0200 cfg80211/mac80211: ignore signal if the frame was heard on wrong channel Reported-by: Aaro Koskinen Signed-off-by: Rafał Miłecki Tested-by: Aaro Koskinen Signed-off-by: John W. Linville Signed-off-by: Ben Hutchings commit 46b9b0e6598839525343d98aae525bcbf294e7bd Author: Stanislaw Gruszka Date: Tue Jun 10 12:51:06 2014 +0200 rt2x00: disable TKIP on USB commit 8edcb0ba0d56f5914eef11eda6db8bfe74eb9ca8 upstream. On USB we can not get atomically TKIP key. We have to disable support for TKIP acceleration on USB hardware to avoid bug as showed bellow. [ 860.827243] BUG: scheduling while atomic: hostapd/3397/0x00000002 [ 860.827280] Call Trace: [ 860.827282] [] dump_stack+0x4d/0x66 [ 860.827284] [] __schedule_bug+0x47/0x55 [ 860.827285] [] __schedule+0x733/0x7b0 [ 860.827287] [] schedule+0x29/0x70 [ 860.827289] [] schedule_timeout+0x15a/0x2b0 [ 860.827291] [] ? ftrace_raw_event_tick_stop+0xc0/0xc0 [ 860.827294] [] ? __module_text_address+0x12/0x70 [ 860.827296] [] wait_for_completion_timeout+0xb3/0x140 [ 860.827298] [] ? wake_up_state+0x20/0x20 [ 860.827301] [] usb_start_wait_urb+0x7d/0x150 [ 860.827303] [] usb_control_msg+0xc5/0x110 [ 860.827305] [] rt2x00usb_vendor_request+0xc6/0x160 [rt2x00usb] [ 860.827307] [] rt2x00usb_vendor_req_buff_lock+0x75/0x150 [rt2x00usb] [ 860.827309] [] rt2x00usb_vendor_request_buff+0xa3/0xe0 [rt2x00usb] [ 860.827311] [] rt2x00usb_register_multiread+0x33/0x40 [rt2800usb] [ 860.827314] [] rt2800_get_tkip_seq+0x39/0x50 [rt2800lib] [ 860.827321] [] ieee80211_get_key+0x218/0x2a0 [mac80211] [ 860.827322] [] ? __nlmsg_put+0x6c/0x80 [ 860.827329] [] nl80211_get_key+0x22e/0x360 [cfg80211] Reported-and-tested-by: Peter Wu Reported-and-tested-by: Pontus Fuchs Signed-off-by: Stanislaw Gruszka Signed-off-by: John W. Linville Signed-off-by: Ben Hutchings commit 373d1dfcffc63c68184419264a7eaed422c7958e Author: Johan Hedberg Date: Mon Jun 9 13:58:14 2014 +0300 Bluetooth: Fix SSP acceptor just-works confirmation without MITM commit ba15a58b179ed76a7e887177f2b06de12c58ec8f upstream. From the Bluetooth Core Specification 4.1 page 1958: "if both devices have set the Authentication_Requirements parameter to one of the MITM Protection Not Required options, authentication stage 1 shall function as if both devices set their IO capabilities to DisplayOnly (e.g., Numeric comparison with automatic confirmation on both devices)" So far our implementation has done user confirmation for all just-works cases regardless of the MITM requirements, however following the specification to the word means that we should not be doing confirmation when neither side has the MITM flag set. Signed-off-by: Johan Hedberg Tested-by: Szymon Janc Signed-off-by: Marcel Holtmann [bwh: Backported to 3.2: s/conn->flags/conn->pend/] Signed-off-by: Ben Hutchings commit d6b05102d11032e0809dabc7231cbcdb6eba4cdc Author: Johan Hedberg Date: Tue Jun 10 09:54:24 2014 +0300 Bluetooth: Fix check for connection encryption commit e694788d73efe139b24f78b036deb97fe57fa8cb upstream. The conn->link_key variable tracks the type of link key in use. It is set whenever we respond to a link key request as well as when we get a link key notification event. These two events do not however always guarantee that encryption is enabled: getting a link key request and responding to it may only mean that the remote side has requested authentication but not encryption. On the other hand, the encrypt change event is a certain guarantee that encryption is enabled. The real encryption state is already tracked in the conn->link_mode variable through the HCI_LM_ENCRYPT bit. This patch fixes a check for encryption in the hci_conn_auth function to use the proper conn->link_mode value and thereby eliminates the chance of a false positive result. Signed-off-by: Johan Hedberg Signed-off-by: Marcel Holtmann [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit f7500568b7633324e7c4282bb8baa3ff3f17fd7a Author: Lars-Peter Clausen Date: Wed Jun 18 13:32:35 2014 +0200 ALSA: control: Make sure that id->index does not overflow commit 883a1d49f0d77d30012f114b2e19fc141beb3e8e upstream. The ALSA control code expects that the range of assigned indices to a control is continuous and does not overflow. Currently there are no checks to enforce this. If a control with a overflowing index range is created that control becomes effectively inaccessible and unremovable since snd_ctl_find_id() will not be able to find it. This patch adds a check that makes sure that controls with a overflowing index range can not be created. Signed-off-by: Lars-Peter Clausen Acked-by: Jaroslav Kysela Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings commit e3ca27c942102af152aabb2d2a4ab5fa0abe7d95 Author: Lars-Peter Clausen Date: Wed Jun 18 13:32:34 2014 +0200 ALSA: control: Handle numid overflow commit ac902c112d90a89e59916f751c2745f4dbdbb4bd upstream. Each control gets automatically assigned its numids when the control is created. The allocation is done by incrementing the numid by the amount of allocated numids per allocation. This means that excessive creation and destruction of controls (e.g. via SNDRV_CTL_IOCTL_ELEM_ADD/REMOVE) can cause the id to eventually overflow. Currently when this happens for the control that caused the overflow kctl->id.numid + kctl->count will also over flow causing it to be smaller than kctl->id.numid. Most of the code assumes that this is something that can not happen, so we need to make sure that it won't happen Signed-off-by: Lars-Peter Clausen Acked-by: Jaroslav Kysela Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings commit 79b789d8e20e22196285ac98247b5aeee2cade17 Author: Lars-Peter Clausen Date: Wed Jun 18 13:32:33 2014 +0200 ALSA: control: Don't access controls outside of protected regions commit fd9f26e4eca5d08a27d12c0933fceef76ed9663d upstream. A control that is visible on the card->controls list can be freed at any time. This means we must not access any of its memory while not holding the controls_rw_lock. Otherwise we risk a use after free access. Signed-off-by: Lars-Peter Clausen Acked-by: Jaroslav Kysela Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings commit 0e2e43eca302b31f64ebfe4734fd2cc7358c4555 Author: Lars-Peter Clausen Date: Wed Jun 18 13:32:32 2014 +0200 ALSA: control: Fix replacing user controls commit 82262a46627bebb0febcc26664746c25cef08563 upstream. There are two issues with the current implementation for replacing user controls. The first is that the code does not check if the control is actually a user control and neither does it check if the control is owned by the process that tries to remove it. That allows userspace applications to remove arbitrary controls, which can cause a user after free if a for example a driver does not expect a control to be removed from under its feed. The second issue is that on one hand when a control is replaced the user_ctl_count limit is not checked and on the other hand the user_ctl_count is increased (even though the number of user controls does not change). This allows userspace, once the user_ctl_count limit as been reached, to repeatedly replace a control until user_ctl_count overflows. Once that happens new controls can be added effectively bypassing the user_ctl_count limit. Both issues can be fixed by instead of open-coding the removal of the control that is to be replaced to use snd_ctl_remove_user_ctl(). This function does proper permission checks as well as decrements user_ctl_count after the control has been removed. Note that by using snd_ctl_remove_user_ctl() the check which returns -EBUSY at beginning of the function if the control already exists is removed. This is not a problem though since the check is quite useless, because the lock that is protecting the control list is released between the check and before adding the new control to the list, which means that it is possible that a different control with the same settings is added to the list after the check. Luckily there is another check that is done while holding the lock in snd_ctl_add(), so we'll rely on that to make sure that the same control is not added twice. Signed-off-by: Lars-Peter Clausen Acked-by: Jaroslav Kysela Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings commit 7a3e84b9fd584f2f41600a69fe3cc317b2c34b14 Author: Lars-Peter Clausen Date: Wed Jun 18 13:32:31 2014 +0200 ALSA: control: Protect user controls against concurrent access commit 07f4d9d74a04aa7c72c5dae0ef97565f28f17b92 upstream. The user-control put and get handlers as well as the tlv do not protect against concurrent access from multiple threads. Since the state of the control is not updated atomically it is possible that either two write operations or a write and a read operation race against each other. Both can lead to arbitrary memory disclosure. This patch introduces a new lock that protects user-controls from concurrent access. Since applications typically access controls sequentially than in parallel a single lock per card should be fine. Signed-off-by: Lars-Peter Clausen Acked-by: Jaroslav Kysela Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings commit 389b175f41fdcca5af03cb9e0cb21283e910524c Author: Alan Stern Date: Tue Jun 3 11:00:27 2014 -0400 USB: EHCI: avoid BIOS handover on the HASEE E200 commit b0a50e92bda3c4aeb8017d4e6c6e92146ebd5c9b upstream. Leandro Liptak reports that his HASEE E200 computer hangs when we ask the BIOS to hand over control of the EHCI host controller. This definitely sounds like a bug in the BIOS, but at the moment there is no way to fix it. This patch works around the problem by avoiding the handoff whenever the motherboard and BIOS version match those of Leandro's computer. Signed-off-by: Alan Stern Reported-by: Leandro Liptak Tested-by: Leandro Liptak Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit b5177f732041aa39e3bfd6bb2e5f43e04e76a4a5 Author: Thomas Gleixner Date: Wed Jun 11 18:44:04 2014 +0000 rtmutex: Plug slow unlock race commit 27e35715df54cbc4f2d044f681802ae30479e7fb upstream. When the rtmutex fast path is enabled the slow unlock function can create the following situation: spin_lock(foo->m->wait_lock); foo->m->owner = NULL; rt_mutex_lock(foo->m); <-- fast path free = atomic_dec_and_test(foo->refcnt); rt_mutex_unlock(foo->m); <-- fast path if (free) kfree(foo); spin_unlock(foo->m->wait_lock); <--- Use after free. Plug the race by changing the slow unlock to the following scheme: while (!rt_mutex_has_waiters(m)) { /* Clear the waiters bit in m->owner */ clear_rt_mutex_waiters(m); owner = rt_mutex_owner(m); spin_unlock(m->wait_lock); if (cmpxchg(m->owner, owner, 0) == owner) return; spin_lock(m->wait_lock); } So in case of a new waiter incoming while the owner tries the slow path unlock we have two situations: unlock(wait_lock); lock(wait_lock); cmpxchg(p, owner, 0) == owner mark_rt_mutex_waiters(lock); acquire(lock); Or: unlock(wait_lock); lock(wait_lock); mark_rt_mutex_waiters(lock); cmpxchg(p, owner, 0) != owner enqueue_waiter(); unlock(wait_lock); lock(wait_lock); wakeup_next waiter(); unlock(wait_lock); lock(wait_lock); acquire(lock); If the fast path is disabled, then the simple m->owner = NULL; unlock(m->wait_lock); is sufficient as all access to m->owner is serialized via m->wait_lock; Also document and clarify the wakeup_next_waiter function as suggested by Oleg Nesterov. Reported-by: Steven Rostedt Signed-off-by: Thomas Gleixner Reviewed-by: Steven Rostedt Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/20140611183852.937945560@linutronix.de Signed-off-by: Thomas Gleixner [bwh: Backported to 3.2: adjust filename] Signed-off-by: Ben Hutchings commit faeac1e13e52a0d44c5cb32bf69ad3fe47070560 Author: Thomas Gleixner Date: Thu Jun 5 11:16:12 2014 +0200 rtmutex: Detect changes in the pi lock chain commit 82084984383babe728e6e3c9a8e5c46278091315 upstream. When we walk the lock chain, we drop all locks after each step. So the lock chain can change under us before we reacquire the locks. That's harmless in principle as we just follow the wrong lock path. But it can lead to a false positive in the dead lock detection logic: T0 holds L0 T0 blocks on L1 held by T1 T1 blocks on L2 held by T2 T2 blocks on L3 held by T3 T4 blocks on L4 held by T4 Now we walk the chain lock T1 -> lock L2 -> adjust L2 -> unlock T1 -> lock T2 -> adjust T2 -> drop locks T2 times out and blocks on L0 Now we continue: lock T2 -> lock L0 -> deadlock detected, but it's not a deadlock at all. Brad tried to work around that in the deadlock detection logic itself, but the more I looked at it the less I liked it, because it's crystal ball magic after the fact. We actually can detect a chain change very simple: lock T1 -> lock L2 -> adjust L2 -> unlock T1 -> lock T2 -> adjust T2 -> next_lock = T2->pi_blocked_on->lock; drop locks T2 times out and blocks on L0 Now we continue: lock T2 -> if (next_lock != T2->pi_blocked_on->lock) return; So if we detect that T2 is now blocked on a different lock we stop the chain walk. That's also correct in the following scenario: lock T1 -> lock L2 -> adjust L2 -> unlock T1 -> lock T2 -> adjust T2 -> next_lock = T2->pi_blocked_on->lock; drop locks T3 times out and drops L3 T2 acquires L3 and blocks on L4 now Now we continue: lock T2 -> if (next_lock != T2->pi_blocked_on->lock) return; We don't have to follow up the chain at that point, because T2 propagated our priority up to T4 already. [ Folded a cleanup patch from peterz ] Signed-off-by: Thomas Gleixner Reported-by: Brad Mouring Cc: Steven Rostedt Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/20140605152801.930031935@linutronix.de [bwh: Backported to 3.2: adjust filename, context] Signed-off-by: Ben Hutchings commit 95f9aded9436aa3ce714aeff3f45fcc1431df7d2 Author: Thomas Gleixner Date: Thu Jun 5 12:34:23 2014 +0200 rtmutex: Handle deadlock detection smarter commit 3d5c9340d1949733eb37616abd15db36aef9a57c upstream. Even in the case when deadlock detection is not requested by the caller, we can detect deadlocks. Right now the code stops the lock chain walk and keeps the waiter enqueued, even on itself. Silly not to yell when such a scenario is detected and to keep the waiter enqueued. Return -EDEADLK unconditionally and handle it at the call sites. The futex calls return -EDEADLK. The non futex ones dequeue the waiter, throw a warning and put the task into a schedule loop. Tagged for stable as it makes the code more robust. Signed-off-by: Thomas Gleixner Cc: Steven Rostedt Cc: Peter Zijlstra Cc: Brad Mouring Link: http://lkml.kernel.org/r/20140605152801.836501969@linutronix.de Signed-off-by: Thomas Gleixner [bwh: Backported to 3.2: adjust filenames] Signed-off-by: Ben Hutchings commit d857054b1160cdc83ad0c3dc4db406dbabcf125b Author: Andrey Ryabinin Date: Fri Jun 6 19:09:30 2014 +0400 mm: rmap: fix use-after-free in __put_anon_vma commit 624483f3ea82598ab0f62f1bdb9177f531ab1892 upstream. While working address sanitizer for kernel I've discovered use-after-free bug in __put_anon_vma. For the last anon_vma, anon_vma->root freed before child anon_vma. Later in anon_vma_free(anon_vma) we are referencing to already freed anon_vma->root to check rwsem. This fixes it by freeing the child anon_vma before freeing anon_vma->root. Signed-off-by: Andrey Ryabinin Acked-by: Peter Zijlstra Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit 2aef2e3b9192dc9f99eb1061fa2206eb399e7740 Author: David Henningsson Date: Fri Jun 13 11:15:44 2014 +0200 ALSA: hda - Add quirk for external mic on Lifebook U904 commit 2041d56464a067461d7cc21734a0f024587ed2ff upstream. According to the bug reporter (Данило Шеган), the external mic starts to work and has proper jack detection if only pin 0x19 is marked properly as an external headset mic. AlsaInfo at https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1328587/+attachment/4128991/+files/AlsaInfo.txt BugLink: https://bugs.launchpad.net/bugs/1328587 Signed-off-by: David Henningsson Signed-off-by: Takashi Iwai [bwh: Backported to 3.2: - s/struct hda_pintbl/struct alc_pincfg/ - s/HDA_FIXUP_PINS/ALC_FIXUP_PINS/ Signed-off-by: Ben Hutchings commit 0d2b9938c49c716b35409aefee188e8c0b95d537 Author: Mimi Zohar Date: Sun May 11 00:05:23 2014 -0400 evm: prohibit userspace writing 'security.evm' HMAC value commit 2fb1c9a4f2dbc2f0bd2431c7fa64d0b5483864e4 upstream. Calculating the 'security.evm' HMAC value requires access to the EVM encrypted key. Only the kernel should have access to it. This patch prevents userspace tools(eg. setfattr, cp --preserve=xattr) from setting/modifying the 'security.evm' HMAC value directly. Signed-off-by: Mimi Zohar Signed-off-by: Ben Hutchings commit 335a4d5ba599428c32e6bdf726cd7f20553220a9 Author: Michael Neuling Date: Fri Jun 6 14:28:51 2014 +1000 powerpc: Don't setup CPUs with bad status commit 59a53afe70fd530040bdc69581f03d880157f15a upstream. OPAL will mark a CPU that is guarded as "bad" in the status property of the CPU node. Unfortunatley Linux doesn't check this property and will put the bad CPU in the present map. This has caused hangs on booting when we try to unsplit the core. This patch checks the CPU is avaliable via this status property before putting it in the present map. Signed-off-by: Michael Neuling Tested-by: Anton Blanchard Signed-off-by: Benjamin Herrenschmidt [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit bb262325634570b71c7a3c0c338a2a509d0c9200 Author: Gabor Juhos Date: Wed Apr 16 11:34:41 2014 +0200 watchdog: ath79_wdt: avoid spurious restarts on AR934x commit 23afeb613ec0e10aecfae7838a14d485db62ac52 upstream. On some AR934x based systems, where the frequency of the AHB bus is relatively high, the built-in watchdog causes a spurious restart when it gets enabled. The possible cause of these restarts is that the timeout value written into the TIMER register does not reaches the hardware in time. Add an explicit delay into the ath79_wdt_enable function to avoid the spurious restarts. Signed-off-by: Gabor Juhos Reviewed-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 38831a0a5984c10d6763aba7e3fffe7fe04a1741 Author: Andy Lutomirski Date: Wed May 28 23:09:58 2014 -0400 auditsc: audit_krule mask accesses need bounds checking commit a3c54931199565930d6d84f4c3456f6440aefd41 upstream. Fixes an easy DoS and possible information disclosure. This does nothing about the broken state of x32 auditing. eparis: If the admin has enabled auditd and has specifically loaded audit rules. This bug has been around since before git. Wow... Signed-off-by: Andy Lutomirski Signed-off-by: Eric Paris Signed-off-by: Linus Torvalds [bwh: Backported to 3.2: audit_filter_inode_name() is not a separate function but part of audit_filter_inodes()] Signed-off-by: Ben Hutchings commit 191fe265097bcc50471cda5e1a0112216dbd438d Author: Christian König Date: Wed Jun 4 15:29:56 2014 +0200 drm/radeon: stop poisoning the GART TLB commit 0986c1a55ca64b44ee126a2f719a6e9f28cbe0ed upstream. When we set the valid bit on invalid GART entries they are loaded into the TLB when an adjacent entry is loaded. This poisons the TLB with invalid entries which are sometimes not correctly removed on TLB flush. For stable inclusion the patch probably needs to be modified a bit. Signed-off-by: Christian König Signed-off-by: Alex Deucher [bwh: Backported to 3.2: R600_PTE_GART is not defined and we list all the flags indvidually] Signed-off-by: Ben Hutchings commit 232270aa2ac2e463afd41cd38665ddb275277d79 Author: Chris Mason Date: Wed May 21 05:49:54 2014 -0700 Btrfs: fix double free in find_lock_delalloc_range commit 7d78874273463a784759916fc3e0b4e2eb141c70 upstream. We need to NULL the cached_state after freeing it, otherwise we might free it again if find_delalloc_range doesn't find anything. Signed-off-by: Chris Mason Signed-off-by: Ben Hutchings commit 858454485f3794190a6dcffcd1866cc21a952fd1 Author: J. Bruce Fields Date: Tue May 27 11:14:26 2014 -0400 nfsd4: fix FREE_STATEID lockowner leak commit 48385408b45523d9a432c66292d47ef43efcbb94 upstream. 27b11428b7de ("nfsd4: remove lockowner when removing lock stateid") introduced a memory leak. Reported-by: Jeff Layton Signed-off-by: J. Bruce Fields Signed-off-by: Ben Hutchings commit 19475c82c49aa1e527f20b8918b858960d5e9dac Author: Benjamin Tissoires Date: Sat Jun 7 22:37:47 2014 -0700 Input: synaptics - fix resolution for manually provided min/max commit d49cb7aeebb974713f9f7ab2991352d3050b095b upstream. commit 421e08c41fda fixed the reported min/max for the X and Y axis, but unfortunately, it broke the resolution of those same axis. On the t540p, the resolution is the same regarding X and Y. It is not a problem for xf86-input-synaptics because this driver is only interested in the ratio between X and Y. Unfortunately, xf86-input-cmt uses directly the resolution, and having a null resolution leads to some divide by 0 errors, which are translated by -infinity in the resulting coordinates. Reported-by: Peter Hutterer Signed-off-by: Benjamin Tissoires Signed-off-by: Dmitry Torokhov [bwh: Backported to 3.2: I didn't apply the PNP ID changes, so the code being moved looks different] Signed-off-by: Ben Hutchings commit cb70ede3576b9bfc634d52b93940b1e2db6a6c18 Author: Hans de Goede Date: Sat Jun 7 23:07:13 2014 -0700 Input: elantech - don't set bit 1 of reg_10 when the no_hw_res quirk is set commit fb4f8f568a9def02240ef9bf7aabd246dc63a081 upstream. The touchpad on the GIGABYTE U2442 not only stops communicating when we try to set bit 3 (enable real hardware resolution) of reg_10, but on some BIOS versions also when we set bit 1 (enable two finger mode auto correct). I've asked the original reporter of: https://bugzilla.kernel.org/show_bug.cgi?id=61151 To check that not setting bit 1 does not lead to any adverse effects on his model / BIOS revision, and it does not, so this commit fixes the touchpad not working on these versions by simply never setting bit 1 for laptop models with the no_hw_res quirk. Reported-and-tested-by: James Lademann Tested-by: Philipp Wolfer Signed-off-by: Hans de Goede Signed-off-by: Dmitry Torokhov Signed-off-by: Ben Hutchings commit 714e2d65c9011106c5b4bbfdbf0c1b284545092a Author: Hans de Goede Date: Sat Jun 7 22:35:07 2014 -0700 Input: elantech - deal with clickpads reporting right button events commit cd9e83e2754465856097f31c7ab933ce74c473f8 upstream. At least the Dell Vostro 5470 elantech *clickpad* reports right button clicks when clicked in the right bottom area: https://bugzilla.redhat.com/show_bug.cgi?id=1103528 This is different from how (elantech) clickpads normally operate, normally no matter where the user clicks on the pad the pad always reports a left button event, since there is only 1 hardware button beneath the path. It looks like Dell has put 2 buttons under the pad, one under each bottom corner, causing this. Since this however still clearly is a real clickpad hardware-wise, we still want to report it as such to userspace, so that things like finger movement in the bottom area can be properly ignored as it should be on clickpads. So deal with this weirdness by simply mapping a right click to a left click on elantech clickpads. As an added advantage this is something which we can simply do on all elantech clickpads, so no need to add special quirks for this weird model. Reported-and-tested-by: Elder Marco Signed-off-by: Hans de Goede Signed-off-by: Dmitry Torokhov Signed-off-by: Ben Hutchings commit 5ab98da06723d94a4423735c660c89245b6242bc Author: Lai Jiangshan Date: Fri Jun 6 14:37:10 2014 -0700 idr: fix overflow bug during maximum ID calculation at maximum height commit 3afb69cb5572b3c8c898c00880803cf1a49852c4 upstream. idr_replace() open-codes the logic to calculate the maximum valid ID given the height of the idr tree; unfortunately, the open-coded logic doesn't account for the fact that the top layer may have unused slots and over-shifts the limit to zero when the tree is at its maximum height. The following test code shows it fails to replace the value for id=((1<<27)+42): static void test5(void) { int id; DEFINE_IDR(test_idr); #define TEST5_START ((1<<27)+42) /* use the highest layer */ printk(KERN_INFO "Start test5\n"); id = idr_alloc(&test_idr, (void *)1, TEST5_START, 0, GFP_KERNEL); BUG_ON(id != TEST5_START); TEST_BUG_ON(idr_replace(&test_idr, (void *)2, TEST5_START) != (void *)1); idr_destroy(&test_idr); printk(KERN_INFO "End of test5\n"); } Fix the bug by using idr_max() which correctly takes into account the maximum allowed shift. sub_alloc() shares the same problem and may incorrectly fail with -EAGAIN; however, this bug doesn't affect correct operation because idr_get_empty_slot(), which already uses idr_max(), retries with the increased @id in such cases. [tj@kernel.org: Updated patch description.] Signed-off-by: Lai Jiangshan Acked-by: Tejun Heo Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 0b8ad905025a3b00172bcd245072a3ba98db0a52 Author: Matthew Dempsky Date: Fri Jun 6 14:36:42 2014 -0700 ptrace: fix fork event messages across pid namespaces commit 4e52365f279564cef0ddd41db5237f0471381093 upstream. When tracing a process in another pid namespace, it's important for fork event messages to contain the child's pid as seen from the tracer's pid namespace, not the parent's. Otherwise, the tracer won't be able to correlate the fork event with later SIGTRAP signals it receives from the child. We still risk a race condition if a ptracer from a different pid namespace attaches after we compute the pid_t value. However, sending a bogus fork event message in this unlikely scenario is still a vast improvement over the status quo where we always send bogus fork event messages to debuggers in a different pid namespace than the forking process. Signed-off-by: Matthew Dempsky Acked-by: Oleg Nesterov Cc: Kees Cook Cc: Julien Tinnes Cc: Roland McGrath Cc: Jan Kratochvil Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 6df2529a3af404bc367fcf37cd3203c1d4951675 Author: Boris BREZILLON Date: Fri Jun 6 14:36:09 2014 -0700 rtc: rtc-at91rm9200: fix infinite wait for ACKUPD irq commit 2fe121e1f5aa3bf31b418a9790db6c400e922291 upstream. The rtc user must wait at least 1 sec between each time/calandar update (see atmel's datasheet chapter "Updating Time/Calendar"). Use the 1Hz interrupt to update the at91_rtc_upd_rdy flag and wait for the at91_rtc_wait_upd_rdy event if the rtc is not ready. This patch fixes a deadlock in an uninterruptible wait when the RTC is updated more than once every second. AFAICT the bug is here from the beginning, but I think we should at least backport this fix to 3.10 and the following longterm and stable releases. Signed-off-by: Boris BREZILLON Reported-by: Bryan Evenson Tested-by: Bryan Evenson Cc: Andrew Victor Cc: Nicolas Ferre Cc: Jean-Christophe Plagniol-Villard Cc: Alessandro Zummo Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds [bwh: Backported to 3.2: - Adjust context - at91_rtc_write() is called at91_sys_write() - Use at91_sys_write() directly instead of the missing at91_rtc_write_ier() and at91_rtc_write_idr()] Signed-off-by: Ben Hutchings commit e70d6e73d06522b3c8c7a145a97e37387b2cb35b Author: Johannes Weiner Date: Fri Jun 6 14:35:35 2014 -0700 mm: vmscan: clear kswapd's special reclaim powers before exiting commit 71abdc15adf8c702a1dd535f8e30df50758848d2 upstream. When kswapd exits, it can end up taking locks that were previously held by allocating tasks while they waited for reclaim. Lockdep currently warns about this: On Wed, May 28, 2014 at 06:06:34PM +0800, Gu Zheng wrote: > inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-R} usage. > kswapd2/1151 [HC0[0]:SC0[0]:HE1:SE1] takes: > (&sig->group_rwsem){+++++?}, at: exit_signals+0x24/0x130 > {RECLAIM_FS-ON-W} state was registered at: > mark_held_locks+0xb9/0x140 > lockdep_trace_alloc+0x7a/0xe0 > kmem_cache_alloc_trace+0x37/0x240 > flex_array_alloc+0x99/0x1a0 > cgroup_attach_task+0x63/0x430 > attach_task_by_pid+0x210/0x280 > cgroup_procs_write+0x16/0x20 > cgroup_file_write+0x120/0x2c0 > vfs_write+0xc0/0x1f0 > SyS_write+0x4c/0xa0 > tracesys+0xdd/0xe2 > irq event stamp: 49 > hardirqs last enabled at (49): _raw_spin_unlock_irqrestore+0x36/0x70 > hardirqs last disabled at (48): _raw_spin_lock_irqsave+0x2b/0xa0 > softirqs last enabled at (0): copy_process.part.24+0x627/0x15f0 > softirqs last disabled at (0): (null) > > other info that might help us debug this: > Possible unsafe locking scenario: > > CPU0 > ---- > lock(&sig->group_rwsem); > > lock(&sig->group_rwsem); > > *** DEADLOCK *** > > no locks held by kswapd2/1151. > > stack backtrace: > CPU: 30 PID: 1151 Comm: kswapd2 Not tainted 3.10.39+ #4 > Call Trace: > dump_stack+0x19/0x1b > print_usage_bug+0x1f7/0x208 > mark_lock+0x21d/0x2a0 > __lock_acquire+0x52a/0xb60 > lock_acquire+0xa2/0x140 > down_read+0x51/0xa0 > exit_signals+0x24/0x130 > do_exit+0xb5/0xa50 > kthread+0xdb/0x100 > ret_from_fork+0x7c/0xb0 This is because the kswapd thread is still marked as a reclaimer at the time of exit. But because it is exiting, nobody is actually waiting on it to make reclaim progress anymore, and it's nothing but a regular thread at this point. Be tidy and strip it of all its powers (PF_MEMALLOC, PF_SWAPWRITE, PF_KSWAPD, and the lockdep reclaim state) before returning from the thread function. Signed-off-by: Johannes Weiner Reported-by: Gu Zheng Cc: Yasuaki Ishimatsu Cc: Tang Chen Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit 9ae0f3c0d18c443a72664577bdb70fe30f796b7d Author: Nicholas Bellinger Date: Thu Jun 5 18:08:57 2014 -0700 iscsi-target: Reject mutual authentication with reflected CHAP_C commit 1d2b60a5545942b1376cb48c1d55843d71e3a08f upstream. This patch adds an explicit check in chap_server_compute_md5() to ensure the CHAP_C value received from the initiator during mutual authentication does not match the original CHAP_C provided by the target. This is in line with RFC-3720, section 8.2.1: Originators MUST NOT reuse the CHAP challenge sent by the Responder for the other direction of a bidirectional authentication. Responders MUST check for this condition and close the iSCSI TCP connection if it occurs. Reported-by: Tejas Vaykole Signed-off-by: Nicholas Bellinger Signed-off-by: Ben Hutchings commit 4e53b9de24ecec036a8f6c8acae25e426a8bdab1 Author: Kailang Yang Date: Thu Jun 5 11:13:44 2014 +0800 ALSA: hda/realtek - Add support of ALC891 codec commit b6c5fbad16aa5026f508093a8d651c25e1cb6179 upstream. New codec support for ALC891. Signed-off-by: Kailang Yang Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings commit 19e84f234b21b7cea051f109381c2f839e4dbc7e Author: Benjamin Herrenschmidt Date: Tue Jun 3 17:33:41 2014 +1000 powerpc/serial: Use saner flags when creating legacy ports commit c4cad90f9e9dcb85afc5e75a02ae3522ed077296 upstream. We had a mix & match of flags used when creating legacy ports depending on where we found them in the device-tree. Among others we were missing UPF_SKIP_TEST for some kind of ISA ports which is a problem as quite a few UARTs out there don't support the loopback test (such as a lot of BMCs). Let's pick the set of flags used by the SoC code and generalize it which means autoconf, no loopback test, irq maybe shared and fixed port. Sending to stable as the lack of UPF_SKIP_TEST is breaking serial on some machines so I want this back into distros Signed-off-by: Benjamin Herrenschmidt [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit e3ffaedcd935237fa5f1d820cb6ad33810593079 Author: Hugh Dickins Date: Wed Jun 4 16:05:33 2014 -0700 mm: fix sleeping function warning from __put_anon_vma commit 7f39dda9d86fb4f4f17af0de170decf125726f8c upstream. Trinity reports BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:47 in_atomic(): 0, irqs_disabled(): 0, pid: 5787, name: trinity-c27 __might_sleep < down_write < __put_anon_vma < page_get_anon_vma < migrate_pages < compact_zone < compact_zone_order < try_to_compact_pages .. Right, since conversion to mutex then rwsem, we should not put_anon_vma() from inside an rcu_read_lock()ed section: fix the two places that did so. And add might_sleep() to anon_vma_free(), as suggested by Peter Zijlstra. Fixes: 88c22088bf23 ("mm: optimize page_lock_anon_vma() fast-path") Reported-by: Dave Jones Signed-off-by: Hugh Dickins Cc: Peter Zijlstra Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit ba1ef838a9e275933683edbd08b6e2226f16e351 Author: Benny Halevy Date: Fri May 30 09:09:27 2014 -0400 nfsd4: use recall_lock for delegation hashing commit 931ee56c67573eb4e51c8a4e78598d965b8b059e upstream. This fixes a bug in the handling of the fi_delegations list. nfs4_setlease does not hold the recall_lock when adding to it. The client_mutex is held, which prevents against concurrent list changes, but nfsd_break_deleg_cb does not hold while walking it. New delegations could theoretically creep onto the list while we're walking it there. Signed-off-by: Benny Halevy Signed-off-by: Jeff Layton Signed-off-by: J. Bruce Fields [bwh: Backported to 3.2: - Adjust context - Also remove a list_del_init() in nfs4_setlease() which would now be before the corresponding list_add() - Drop change to nfsd_find_all_delegations(), which doesn't exist] Signed-off-by: Ben Hutchings commit 13ce2ab0f6dc3ce7ee779b204786b7e501ac5c1b Author: Jérôme Carretero Date: Tue Jun 3 14:56:25 2014 -0400 ahci: Add Device ID for HighPoint RocketRaid 642L commit d251836508fb26cd1a22b41381739835ee23728d upstream. This device normally comes with a proprietary driver, using a web GUI to configure RAID: http://www.highpoint-tech.com/USA_new/series_rr600-download.htm But thankfully it also works out of the box with the AHCI driver, being just a Marvell 88SE9235. Devices 640L, 644L, 644LS should also be supported but not tested here. Signed-off-by: Jérôme Carretero Signed-off-by: Tejun Heo Signed-off-by: Ben Hutchings commit 3c010c0b090cb5e2dceeee45bbf0d7aaee9e8378 Author: Alex Deucher Date: Mon Apr 21 21:45:09 2014 -0400 drm/radeon: only apply hdmi bpc pll flags when encoder mode is hdmi commit 7d5ab3009a8ca777174f6f469277b3922d56fd4b upstream. May fix display issues with non-HDMI displays. Signed-off-by: Alex Deucher Signed-off-by: Ben Hutchings commit 94264f44b2f4715806d401c9f6e65b2458f70fe5 Author: Alex Deucher Date: Tue May 27 16:40:51 2014 -0400 drm/radeon/atom: fix dithering on certain panels commit 642528355c694f5ed68f6bff9ff520326a249f99 upstream. We need to specify the encoder mode as LVDS for eDP when using the Crtc_Source atom table in order to properly set up the FMT hardware. bug: https://bugs.freedesktop.org/show_bug.cgi?id=73911 Signed-off-by: Alex Deucher Signed-off-by: Ben Hutchings commit 08e6c752d89cf72e793a4ea3487692096d476f1a Author: Alex Deucher Date: Tue May 27 13:11:36 2014 -0400 drm/radeon: fix typo in radeon_connector_is_dp12_capable() commit af5d36539dfe043f1cf0f8b7334d6bb12cd14e75 upstream. We were checking the ext clock rather than the display clock. Noticed by ArtForz on IRC. Signed-off-by: Alex Deucher Signed-off-by: Ben Hutchings commit a1c97ac5c17df2a74c711b87849044ed2bce6949 Author: hujianyang Date: Sat May 31 11:39:32 2014 +0800 UBIFS: Remove incorrect assertion in shrink_tnc() commit 72abc8f4b4e8574318189886de627a2bfe6cd0da upstream. I hit the same assert failed as Dolev Raviv reported in Kernel v3.10 shows like this: [ 9641.164028] UBIFS assert failed in shrink_tnc at 131 (pid 13297) [ 9641.234078] CPU: 1 PID: 13297 Comm: mmap.test Tainted: G O 3.10.40 #1 [ 9641.234116] [] (unwind_backtrace+0x0/0x12c) from [] (show_stack+0x20/0x24) [ 9641.234137] [] (show_stack+0x20/0x24) from [] (dump_stack+0x20/0x28) [ 9641.234188] [] (dump_stack+0x20/0x28) from [] (shrink_tnc_trees+0x25c/0x350 [ubifs]) [ 9641.234265] [] (shrink_tnc_trees+0x25c/0x350 [ubifs]) from [] (ubifs_shrinker+0x25c/0x310 [ubifs]) [ 9641.234307] [] (ubifs_shrinker+0x25c/0x310 [ubifs]) from [] (shrink_slab+0x1d4/0x2f8) [ 9641.234327] [] (shrink_slab+0x1d4/0x2f8) from [] (do_try_to_free_pages+0x300/0x544) [ 9641.234344] [] (do_try_to_free_pages+0x300/0x544) from [] (try_to_free_pages+0x2d0/0x398) [ 9641.234363] [] (try_to_free_pages+0x2d0/0x398) from [] (__alloc_pages_nodemask+0x494/0x7e8) [ 9641.234382] [] (__alloc_pages_nodemask+0x494/0x7e8) from [] (new_slab+0x78/0x238) [ 9641.234400] [] (new_slab+0x78/0x238) from [] (__slab_alloc.constprop.42+0x1a4/0x50c) [ 9641.234419] [] (__slab_alloc.constprop.42+0x1a4/0x50c) from [] (kmem_cache_alloc_trace+0x54/0x188) [ 9641.234459] [] (kmem_cache_alloc_trace+0x54/0x188) from [] (do_readpage+0x168/0x468 [ubifs]) [ 9641.234553] [] (do_readpage+0x168/0x468 [ubifs]) from [] (ubifs_readpage+0x424/0x464 [ubifs]) [ 9641.234606] [] (ubifs_readpage+0x424/0x464 [ubifs]) from [] (filemap_fault+0x304/0x418) [ 9641.234638] [] (filemap_fault+0x304/0x418) from [] (__do_fault+0xd4/0x530) [ 9641.234665] [] (__do_fault+0xd4/0x530) from [] (handle_pte_fault+0x480/0xf54) [ 9641.234690] [] (handle_pte_fault+0x480/0xf54) from [] (handle_mm_fault+0x140/0x184) [ 9641.234716] [] (handle_mm_fault+0x140/0x184) from [] (do_page_fault+0x150/0x3ac) [ 9641.234737] [] (do_page_fault+0x150/0x3ac) from [] (do_DataAbort+0x3c/0xa0) [ 9641.234759] [] (do_DataAbort+0x3c/0xa0) from [] (__dabt_usr+0x38/0x40) After analyzing the code, I found a condition that may cause this failed in correct operations. Thus, I think this assertion is wrong and should be removed. Suppose there are two clean znodes and one dirty znode in TNC. So the per-filesystem atomic_t @clean_zn_cnt is (2). If commit start, dirty_znode is set to COW_ZNODE in get_znodes_to_commit() in case of potentially ops on this znode. We clear COW bit and DIRTY bit in write_index() without @tnc_mutex locked. We don't increase @clean_zn_cnt in this place. As the comments in write_index() shows, if another process hold @tnc_mutex and dirty this znode after we clean it, @clean_zn_cnt would be decreased to (1). We will increase @clean_zn_cnt to (2) with @tnc_mutex locked in free_obsolete_znodes() to keep it right. If shrink_tnc() performs between decrease and increase, it will release other 2 clean znodes it holds and found @clean_zn_cnt is less than zero (1 - 2 = -1), then hit the assertion. Because free_obsolete_znodes() will soon correct @clean_zn_cnt and no harm to fs in this case, I think this assertion could be removed. 2 clean zondes and 1 dirty znode, @clean_zn_cnt == 2 Thread A (commit) Thread B (write or others) Thread C (shrinker) ->write_index ->clear_bit(DIRTY_NODE) ->clear_bit(COW_ZNODE) @clean_zn_cnt == 2 ->mutex_locked(&tnc_mutex) ->dirty_cow_znode ->!ubifs_zn_cow(znode) ->!test_and_set_bit(DIRTY_NODE) ->atomic_dec(&clean_zn_cnt) ->mutex_unlocked(&tnc_mutex) @clean_zn_cnt == 1 ->mutex_locked(&tnc_mutex) ->shrink_tnc ->destroy_tnc_subtree ->atomic_sub(&clean_zn_cnt, 2) ->ubifs_assert <- hit ->mutex_unlocked(&tnc_mutex) @clean_zn_cnt == -1 ->mutex_lock(&tnc_mutex) ->free_obsolete_znodes ->atomic_inc(&clean_zn_cnt) ->mutux_unlock(&tnc_mutex) @clean_zn_cnt == 0 (correct after shrink) Signed-off-by: hujianyang Signed-off-by: Artem Bityutskiy Signed-off-by: Ben Hutchings commit ad6a6b22ba8e575317467a7ed7ed6c4d24b0fbdf Author: Christoph Hellwig Date: Wed May 28 10:46:13 2014 +0200 nfsd: getattr for FATTR4_WORD0_FILES_AVAIL needs the statfs buffer commit 12337901d654415d9f764b5f5ba50052e9700f37 upstream. Note nobody's ever noticed because the typical client probably never requests FILES_AVAIL without also requesting something else on the list. Signed-off-by: Christoph Hellwig Signed-off-by: J. Bruce Fields Signed-off-by: Ben Hutchings commit e36a18a9f92d082f2f32a627c3be1fd00683acd2 Author: Yann Droneaud Date: Mon May 5 19:33:23 2014 +0200 RDMA/cxgb4: Add missing padding at end of struct c4iw_create_cq_resp commit b6f04d3d21458818073a2f5af5339f958864bf71 upstream. The i386 ABI disagrees with most other ABIs regarding alignment of data types larger than 4 bytes: on most ABIs a padding must be added at end of the structures, while it is not required on i386. So for most ABI struct c4iw_create_cq_resp gets implicitly padded to be aligned on a 8 bytes multiple, while for i386, such padding is not added. The tool pahole can be used to find such implicit padding: $ pahole --anon_include \ --nested_anon_include \ --recursive \ --class_name c4iw_create_cq_resp \ drivers/infiniband/hw/cxgb4/iw_cxgb4.o Then, structure layout can be compared between i386 and x86_64: # +++ obj-i386/drivers/infiniband/hw/cxgb4/iw_cxgb4.o.pahole.txt 2014-03-28 11:43:05.547432195 +0100 # --- obj-x86_64/drivers/infiniband/hw/cxgb4/iw_cxgb4.o.pahole.txt 2014-03-28 10:55:10.990133017 +0100 @@ -14,9 +13,8 @@ struct c4iw_create_cq_resp { __u32 size; /* 28 4 */ __u32 qid_mask; /* 32 4 */ - /* size: 36, cachelines: 1, members: 6 */ - /* last cacheline: 36 bytes */ + /* size: 40, cachelines: 1, members: 6 */ + /* padding: 4 */ + /* last cacheline: 40 bytes */ }; This ABI disagreement will make an x86_64 kernel try to write past the buffer provided by an i386 binary. When boundary check will be implemented, the x86_64 kernel will refuse to write past the i386 userspace provided buffer and the uverbs will fail. If the structure is on a page boundary and the next page is not mapped, ib_copy_to_udata() will fail and the uverb will fail. This patch adds an explicit padding at end of structure c4iw_create_cq_resp, and, like 92b0ca7cb149 ("IB/mlx5: Fix stack info leak in mlx5_ib_alloc_ucontext()"), makes function c4iw_create_cq() not writting this padding field to userspace. This way, x86_64 kernel will be able to write struct c4iw_create_cq_resp as expected by unpatched and patched i386 libcxgb4. Link: http://marc.info/?i=cover.1399309513.git.ydroneaud@opteya.com Fixes: cfdda9d764362 ("RDMA/cxgb4: Add driver for Chelsio T4 RNIC") Fixes: e24a72a3302a6 ("RDMA/cxgb4: Fix four byte info leak in c4iw_create_cq()") Cc: Dan Carpenter Signed-off-by: Yann Droneaud Acked-by: Steve Wise Signed-off-by: Roland Dreier Signed-off-by: Ben Hutchings commit bec3dbf153f5a72ec3d89924a96df0ae913b4699 Author: Dan Carpenter Date: Sat Oct 19 12:14:35 2013 +0300 RDMA/cxgb4: Fix four byte info leak in c4iw_create_cq() commit e24a72a3302a638d4c6e77f0b40c45cc61c3f089 upstream. There is a four byte hole at the end of the "uresp" struct after the ->qid_mask member. Signed-off-by: Dan Carpenter Signed-off-by: Roland Dreier Signed-off-by: Ben Hutchings commit f414d28908c2c9b0833b456c87fbe401513fd975 Author: Bart Van Assche Date: Tue May 20 10:33:41 2014 +0200 IB/umad: Fix error handling commit 8ec0a0e6b58218bdc1db91dd70ebfcd6ad8dd6cd upstream. Avoid leaking a kref count in ib_umad_open() if port->ib_dev == NULL or if nonseekable_open() fails. Avoid leaking a kref count, that sm_sem is kept down and also that the IB_PORT_SM capability mask is not cleared in ib_umad_sm_open() if nonseekable_open() fails. Since container_of() never returns NULL, remove the code that tests whether container_of() returns NULL. Moving the kref_get() call from the start of ib_umad_*open() to the end is safe since it is the responsibility of the caller of these functions to ensure that the cdev pointer remains valid until at least when these functions return. Signed-off-by: Bart Van Assche [ydroneaud@opteya.com: rework a bit to reduce the amount of code changed] Signed-off-by: Yann Droneaud [ nonseekable_open() can't actually fail, but.... - Roland ] Signed-off-by: Roland Dreier Signed-off-by: Ben Hutchings commit 28170033c7ccff7c8ebcf1e648e26f1801e8f198 Author: Mathias Nyman Date: Wed May 28 23:51:13 2014 +0300 xhci: delete endpoints from bandwidth list before freeing whole device commit 5dc2808c4729bf080487e61b80ee04e0fdb12a37 upstream. Lists of endpoints are stored for bandwidth calculation for roothub ports. Make sure we remove all endpoints from the list before the whole device, containing its endpoints list_head stuctures, is freed. This used to be done in the wrong order in xhci_mem_cleanup(), and triggered an oops in resume from S4 (hibernate). Tested-by: Ville Syrjälä Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit d70ca1085a097b191679d6c146b0887d2f5ca3c4 Author: Thomas Gleixner Date: Thu May 22 03:25:39 2014 +0000 rtmutex: Fix deadlock detector for real commit 397335f004f41e5fcf7a795e94eb3ab83411a17c upstream. The current deadlock detection logic does not work reliably due to the following early exit path: /* * Drop out, when the task has no waiters. Note, * top_waiter can be NULL, when we are in the deboosting * mode! */ if (top_waiter && (!task_has_pi_waiters(task) || top_waiter != task_top_pi_waiter(task))) goto out_unlock_pi; So this not only exits when the task has no waiters, it also exits unconditionally when the current waiter is not the top priority waiter of the task. So in a nested locking scenario, it might abort the lock chain walk and therefor miss a potential deadlock. Simple fix: Continue the chain walk, when deadlock detection is enabled. We also avoid the whole enqueue, if we detect the deadlock right away (A-A). It's an optimization, but also prevents that another waiter who comes in after the detection and before the task has undone the damage observes the situation and detects the deadlock and returns -EDEADLOCK, which is wrong as the other task is not in a deadlock situation. Signed-off-by: Thomas Gleixner Cc: Peter Zijlstra Reviewed-by: Steven Rostedt Cc: Lai Jiangshan Link: http://lkml.kernel.org/r/20140522031949.725272460@linutronix.de Signed-off-by: Thomas Gleixner [bwh: Backported to 3.2: adjust filename] Signed-off-by: Ben Hutchings commit 37543a4eb018efe38c35612b4666d92014812563 Author: Arik Nemtsov Date: Mon May 26 14:40:51 2014 +0300 mac80211: don't check netdev state for debugfs read/write commit 923eaf367206e01f22c97aee22300e332d071916 upstream. Doing so will lead to an oops for a p2p-dev interface, since it has no netdev. Signed-off-by: Arik Nemtsov Signed-off-by: Emmanuel Grumbach Signed-off-by: Johannes Berg Signed-off-by: Ben Hutchings commit e4a0cc2688a0d43d54eac22b731a79b6917d138d Author: Christian Borntraeger Date: Mon May 26 21:55:08 2014 +0200 s390/lowcore: reserve 96 bytes for IRB in lowcore commit 993072ee67aa179c48c85eb19869804e68887d86 upstream. The IRB might be 96 bytes if the extended-I/O-measurement facility is used. This feature is currently not used by Linux, but struct irb already has the emw defined. So let's make the irb in lowcore match the size of the internal data structure to be future proof. We also have to add a pad, to correctly align the paste. The bigger irb field also circumvents a bug in some QEMU versions that always write the emw field on test subchannel and therefore destroy the paste definitions of this CPU. Running under these QEMU version broke some timing functions in the VDSO and all users of these functions, e.g. some JREs. Signed-off-by: Christian Borntraeger Signed-off-by: Martin Schwidefsky Cc: Heiko Carstens Cc: Sebastian Ott Cc: Cornelia Huck [bwh: Backported to 3.2: offsets of the affected fields in the 64-bit version of struct _lowcore are 128 bytes smaller] Signed-off-by: Ben Hutchings commit 8197104d1f38f1826bb66e23eda1d06958129439 Author: NeilBrown Date: Wed May 28 13:39:23 2014 +1000 md: always set MD_RECOVERY_INTR when aborting a reshape or other "resync". commit 3991b31ea072b070081ca3bfa860a077eda67de5 upstream. If mddev->ro is set, md_to_sync will (correctly) abort. However in that case MD_RECOVERY_INTR isn't set. If a RESHAPE had been requested, then ->finish_reshape() will be called and it will think the reshape was successful even though nothing happened. Normally a resync will not be requested if ->ro is set, but if an array is stopped while a reshape is on-going, then when the array is started, the reshape will be restarted. If the array is also set read-only at this point, the reshape will instantly appear to success, resulting in data corruption. Consequently, this patch is suitable for any -stable kernel. Signed-off-by: NeilBrown Signed-off-by: Ben Hutchings commit 1e2f98c52b3b79761f9969ae6aef9c079192448b Author: Guenter Roeck Date: Thu May 15 09:33:42 2014 -0700 powerpc: Fix 64 bit builds with binutils 2.24 commit 7998eb3dc700aaf499f93f50b3d77da834ef9e1d upstream. With binutils 2.24, various 64 bit builds fail with relocation errors such as arch/powerpc/kernel/built-in.o: In function `exc_debug_crit_book3e': (.text+0x165ee): relocation truncated to fit: R_PPC64_ADDR16_HI against symbol `interrupt_base_book3e' defined in .text section in arch/powerpc/kernel/built-in.o arch/powerpc/kernel/built-in.o: In function `exc_debug_crit_book3e': (.text+0x16602): relocation truncated to fit: R_PPC64_ADDR16_HI against symbol `interrupt_end_book3e' defined in .text section in arch/powerpc/kernel/built-in.o The assembler maintainer says: I changed the ABI, something that had to be done but unfortunately happens to break the booke kernel code. When building up a 64-bit value with lis, ori, shl, oris, ori or similar sequences, you now should use @high and @higha in place of @h and @ha. @h and @ha (and their associated relocs R_PPC64_ADDR16_HI and R_PPC64_ADDR16_HA) now report overflow if the value is out of 32-bit signed range. ie. @h and @ha assume you're building a 32-bit value. This is needed to report out-of-range -mcmodel=medium toc pointer offsets in @toc@h and @toc@ha expressions, and for consistency I did the same for all other @h and @ha relocs. Replacing @h with @high in one strategic location fixes the relocation errors. This has to be done conditionally since the assembler either supports @h or @high but not both. Signed-off-by: Guenter Roeck Signed-off-by: Benjamin Herrenschmidt [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 895902a9f59aea579a3e9333c48fc45dedc4daee Author: Huang Rui Date: Mon May 26 10:55:36 2014 +0800 usb: usbtest: fix unlink write error with pattern 1 commit e4d58f5dcb7d7be45df8def31881ebfae99c75da upstream. TEST 12 and TEST 24 unlinks the URB write request for N times. When host and gadget both initialize pattern 1 (mod 63) data series to transfer, the gadget side will complain the wrong data which is not expected. Because in host side, usbtest doesn't fill the data buffer as mod 63 and this patch fixed it. [20285.488974] dwc3 dwc3.0.auto: ep1out-bulk: Transfer Not Ready [20285.489181] dwc3 dwc3.0.auto: ep1out-bulk: reason Transfer Not Active [20285.489423] dwc3 dwc3.0.auto: ep1out-bulk: req ffff8800aa6cb480 dma aeb50800 length 512 last [20285.489727] dwc3 dwc3.0.auto: ep1out-bulk: cmd 'Start Transfer' params 00000000 a9eaf000 00000000 [20285.490055] dwc3 dwc3.0.auto: Command Complete --> 0 [20285.490281] dwc3 dwc3.0.auto: ep1out-bulk: Transfer Not Ready [20285.490492] dwc3 dwc3.0.auto: ep1out-bulk: reason Transfer Active [20285.490713] dwc3 dwc3.0.auto: ep1out-bulk: endpoint busy [20285.490909] dwc3 dwc3.0.auto: ep1out-bulk: Transfer Complete [20285.491117] dwc3 dwc3.0.auto: request ffff8800aa6cb480 from ep1out-bulk completed 512/512 ===> 0 [20285.491431] zero gadget: bad OUT byte, buf[1] = 0 [20285.491605] dwc3 dwc3.0.auto: ep1out-bulk: cmd 'Set Stall' params 00000000 00000000 00000000 [20285.491915] dwc3 dwc3.0.auto: Command Complete --> 0 [20285.492099] dwc3 dwc3.0.auto: queing request ffff8800aa6cb480 to ep1out-bulk length 512 [20285.492387] dwc3 dwc3.0.auto: ep1out-bulk: Transfer Not Ready [20285.492595] dwc3 dwc3.0.auto: ep1out-bulk: reason Transfer Not Active [20285.492830] dwc3 dwc3.0.auto: ep1out-bulk: req ffff8800aa6cb480 dma aeb51000 length 512 last [20285.493135] dwc3 dwc3.0.auto: ep1out-bulk: cmd 'Start Transfer' params 00000000 a9eaf000 00000000 [20285.493465] dwc3 dwc3.0.auto: Command Complete --> 0 Signed-off-by: Huang Rui Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 8a652e0c7ba968ad0fa4a27855749dd5659517d5 Author: Alexej Starschenko Date: Wed May 7 10:43:29 2014 +0200 USB: serial: option: add support for Novatel E371 PCIe card commit 8a61ba3a47ac39f660702aa66a172185dd605a86 upstream. Adds product ID for the Novatel E371 PCI Express Mini Card. $ lsusb Bus 001 Device 024: ID 1410:9011 Novatel Wireless $ usb-devices T: Bus=01 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 24 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=1410 ProdID=9011 Rev=00.03 S: Manufacturer=Novatel Wireless, Inc. S: Product=Novatel Wireless HSPA S: SerialNumber=012773002115811 C: #Ifs= 6 Cfg#= 1 Atr=e0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#= 6 Alt= 0 #EPs= 1 Cls=02(commc) Sub=06 Prot=00 Driver=cdc_ether I: If#= 7 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether Tested with kernel 3.2.0. Signed-off-by: Alexej Starschenko Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 53ff52126042f50515fc12e653736cd45e87a2ea Author: George McCollister Date: Sat Apr 26 12:04:47 2014 +0200 USB: ftdi_sio: add NovaTech OrionLXm product ID commit d0839d757e6294921c31b1c4ca4f1dcc5df63bcd upstream. The NovaTech OrionLXm uses an onboard FTDI serial converter for JTAG and console access. Here is the lsusb output: Bus 004 Device 123: ID 0403:7c90 Future Technology Devices International, Ltd Signed-off-by: George McCollister Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 4f2a2b643da6b5cd8aaead422d3778eb8f2584cf Author: Johan Hovold Date: Sat Apr 26 11:53:44 2014 +0200 USB: io_ti: fix firmware download on big-endian machines (part 2) commit c03890ff5e24a4bf59059f2d179f427559b7330a upstream. A recent patch that purported to fix firmware download on big-endian machines failed to add the corresponding sparse annotation to the i2c-header. This was reported by the kbuild test robot. Adding the appropriate annotation revealed another endianess bug related to the i2c-header Size-field in a code path that is exercised when the firmware is actually being downloaded (and not just verified and left untouched unless older than the firmware at hand). This patch adds the required sparse annotation to the i2c-header and makes sure that the Size-field is sent in little-endian byte order during firmware download also on big-endian machines. Note that this patch is only compile-tested, but that there is no functional change for little-endian systems. Reported-by: kbuild test robot Cc: Ludovic Drolez Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 5ddef05cc4fc70feb34fc0cd696edc55af6eccd4 Author: Johan Hovold Date: Mon May 26 19:23:41 2014 +0200 USB: cdc-acm: fix potential urb leak and PM imbalance in write commit 183a45087d126d126e8dd1d9b2602fc129dff9ad upstream. Make sure to check return value of autopm get in write() in order to avoid urb leak and PM counter imbalance on errors. Fixes: 11ea859d64b6 ("USB: additional power savings for cdc-acm devices that support remote wakeup") Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.2: - Adjust context - Error/status variable is called rc, not stat] Signed-off-by: Ben Hutchings commit 57eb9099f3842564bbca138d06069e5053fdb4df Author: Johan Hovold Date: Mon May 26 19:23:39 2014 +0200 USB: cdc-acm: fix runtime PM for control messages commit bae3f4c53585e9a170da9436e0f06919874bda9a upstream. Fix runtime PM handling of control messages by adding the required PM counter operations. Fixes: 11ea859d64b6 ("USB: additional power savings for cdc-acm devices that support remote wakeup") Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit ab05a2e4be115e07f18152b1569ae8522c4e76a3 Author: Johan Hovold Date: Mon May 26 19:23:38 2014 +0200 USB: cdc-acm: fix broken runtime suspend commit 140cb81ac8c625942a1d695875932c615767a526 upstream. The current ACM runtime-suspend implementation is broken in several ways: Firstly, it buffers only the first write request being made while suspended -- any further writes are silently dropped. Secondly, writes being dropped also leak write urbs, which are never reclaimed (until the device is unbound). Thirdly, even the single buffered write is not cleared at shutdown (which may happen before the device is resumed), something which can lead to another urb leak as well as a PM usage-counter leak. Fix this by implementing a delayed-write queue using urb anchors and making sure to discard the queue properly at shutdown. Fixes: 11ea859d64b6 ("USB: additional power savings for cdc-acm devices that support remote wakeup") Reported-by: Xiao Jin Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 161427758577d5b5299c0b897730235a1fa950cc Author: Johan Hovold Date: Mon May 26 19:23:37 2014 +0200 USB: cdc-acm: fix write and resume race commit e144ed28bed10684f9aaec6325ed974d53f76110 upstream. Fix race between write() and resume() due to improper locking that could lead to writes being reordered. Resume must be done atomically and susp_count be protected by the write_lock in order to prevent racing with write(). This could otherwise lead to writes being reordered if write() grabs the write_lock after susp_count is decremented, but before the delayed urb is submitted. Fixes: 11ea859d64b6 ("USB: additional power savings for cdc-acm devices that support remote wakeup") Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.2: - Adjust context - Move mutex_lock(acm->mutex) above acquisition of spinlocks] Signed-off-by: Ben Hutchings commit 3627c07522db92848b8d6414616315028084f5f2 Author: Johan Hovold Date: Mon May 26 19:23:36 2014 +0200 USB: cdc-acm: fix write and suspend race commit 5a345c20c17d87099224a4be12e69e5bd7023dca upstream. Fix race between write() and suspend() which could lead to writes being dropped (or I/O while suspended) if the device is runtime suspended while a write request is being processed. Specifically, suspend() releases the write_lock after determining the device is idle but before incrementing the susp_count, thus leaving a window where a concurrent write() can submit an urb. Fixes: 11ea859d64b6 ("USB: additional power savings for cdc-acm devices that support remote wakeup") Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 75a5d8feae868a9b2d84b719fcf4c975c7e02162 Author: Johan Hovold Date: Mon May 26 19:23:18 2014 +0200 USB: usb_wwan: fix potential blocked I/O after resume commit fb7ad4f93d9f0f7d49beda32f5e7becb94b29a4d upstream. Keep trying to submit urbs rather than bail out on first read-urb submission error, which would also prevent I/O for any further ports from being resumed. Instead keep an error count, for all types of failed submissions, and let USB core know that something went wrong. Also make sure to always clear the suspended flag. Currently a failed read-urb submission would prevent cached writes as well as any subsequent writes from being submitted until next suspend-resume cycle, something which may not even necessarily happen. Note that USB core currently only logs an error if an interface resume failed. Fixes: 383cedc3bb43 ("USB: serial: full autosuspend support for the option driver") Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 19306d4c1e27348d989d519d8c30c5fcd1b998ad Author: Johan Hovold Date: Mon May 26 19:23:16 2014 +0200 USB: usb_wwan: fix urb leak at shutdown commit 79eed03e77d481b55d85d1cfe5a1636a0d3897fd upstream. The delayed-write queue was never emptied at shutdown (close), something which could lead to leaked urbs if the port is closed before being runtime resumed due to a write. When this happens the output buffer would not drain on close (closing_wait timeout), and after consecutive opens, writes could be corrupted with previously buffered data, transfered with reduced throughput or completely blocked. Note that unbusy_queued_urb() was simply moved out of CONFIG_PM. Fixes: 383cedc3bb43 ("USB: serial: full autosuspend support for the option driver") Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.2: adjust indentation] Signed-off-by: Ben Hutchings commit 85296fc41103b19ff46fdb7392fb87fd95c91669 Author: Johan Hovold Date: Mon May 26 19:23:15 2014 +0200 USB: usb_wwan: fix write and suspend race commit 170fad9e22df0063eba0701adb966786d7a4ec5a upstream. Fix race between write() and suspend() which could lead to writes being dropped (or I/O while suspended) if the device is runtime suspended while a write request is being processed. Specifically, suspend() releases the susp_lock after determining the device is idle but before setting the suspended flag, thus leaving a window where a concurrent write() can submit an urb. Fixes: 383cedc3bb43 ("USB: serial: full autosuspend support for the option driver") Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 0985cf0a59c203045a80abfaa5647285673b23ba Author: xiao jin Date: Mon May 26 19:23:14 2014 +0200 USB: usb_wwan: fix race between write and resume commit d9e93c08d8d985e5ef89436ebc9f4aad7e31559f upstream. We find a race between write and resume. usb_wwan_resume run play_delayed() and spin_unlock, but intfdata->suspended still is not set to zero. At this time usb_wwan_write is called and anchor the urb to delay list. Then resume keep running but the delayed urb have no chance to be commit until next resume. If the time of next resume is far away, tty will be blocked in tty_wait_until_sent during time. The race also can lead to writes being reordered. This patch put play_Delayed and intfdata->suspended together in the spinlock, it's to avoid the write race during resume. Fixes: 383cedc3bb43 ("USB: serial: full autosuspend support for the option driver") Signed-off-by: xiao jin Signed-off-by: Zhang, Qi1 Reviewed-by: David Cohen Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.2: there's no need to check for portdata == NULL] Signed-off-by: Ben Hutchings commit 7253b828394395d96c35986a9c7c15665ba2e430 Author: xiao jin Date: Mon May 26 19:23:13 2014 +0200 USB: usb_wwan: fix urb leak in write error path commit db0904737947d509844e171c9863ecc5b4534005 upstream. When enable usb serial for modem data, sometimes the tty is blocked in tty_wait_until_sent because portdata->out_busy always is set and have no chance to be cleared. We find a bug in write error path. usb_wwan_write set portdata->out_busy firstly, then try autopm async with error. No out urb submit and no usb_wwan_outdat_callback to this write, portdata->out_busy can't be cleared. This patch clear portdata->out_busy if usb_wwan_write try autopm async with error. Fixes: 383cedc3bb43 ("USB: serial: full autosuspend support for the option driver") Signed-off-by: xiao jin Signed-off-by: Zhang, Qi1 Reviewed-by: David Cohen Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit e88dd2723f92fffebc51a930228c89df3bdbe92c Author: Johan Hovold Date: Mon May 26 19:23:10 2014 +0200 USB: option: fix runtime PM handling commit acf47d4f9c39b1cba467aa9442fc2efe0b1da741 upstream. Fix potential I/O while runtime suspended due to missing PM operations in send_setup. Fixes: 383cedc3bb43 ("USB: serial: full autosuspend support for the option driver") Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 6513a429cd4d416de148e3d4f5a6432290df83a2 Author: Johan Hovold Date: Mon May 26 19:22:54 2014 +0200 USB: sierra: fix remote wakeup commit 80cc0fcbdaeaf10d04ba27779a2d7ceb73d2717a upstream. Make sure that needs_remote_wake up is always set when there are open ports. Currently close() would unconditionally set needs_remote_wakeup to 0 even though there might still be open ports. This could lead to blocked input and possibly dropped data on devices that do not support remote wakeup (and which must therefore not be runtime suspended while open). Add an open_ports counter (protected by the susp_lock) and only clear needs_remote_wakeup when the last port is closed. Fixes: e6929a9020ac ("USB: support for autosuspend in sierra while online") Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.2: adjust indentation] Signed-off-by: Ben Hutchings commit e4852823d52f1bda6b6dc77d1d4175a36516d832 Author: Johan Hovold Date: Mon May 26 19:22:53 2014 +0200 USB: sierra: fix urb and memory leak on disconnect commit 014333f77c0b71123d6ef7d31a9724e0699c9548 upstream. The delayed-write queue was never emptied on disconnect, something which would lead to leaked urbs and transfer buffers if the device is disconnected before being runtime resumed due to a write. Fixes: e6929a9020ac ("USB: support for autosuspend in sierra while online") Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.2: adjust context, indentation] Signed-off-by: Ben Hutchings commit ffa4bcfce16e2904fed4c9a206f64870086f5539 Author: Johan Hovold Date: Mon May 26 19:22:52 2014 +0200 USB: sierra: fix urb and memory leak in resume error path commit 7fdd26a01eb7b6cb6855ff8f69ef4a720720dfcb upstream. Neither the transfer buffer or the urb itself were released in the resume error path for delayed writes. Also on errors, the remainder of the queue was not even processed, which leads to further urb and buffer leaks. The same error path also failed to balance the outstanding-urb counter, something which results in degraded throughput or completely blocked writes. Fix this by releasing urb and buffer and balancing counters on errors, and by always processing the whole queue even when submission of one urb fails. Fixes: e6929a9020ac ("USB: support for autosuspend in sierra while online") Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 056b08a51466e199b205d55e08144497ea6666ab Author: Johan Hovold Date: Mon May 26 19:22:50 2014 +0200 USB: sierra: fix AA deadlock in open error path commit 353fe198602e8b4d1c7bdcceb8e60955087201b1 upstream. Fix AA deadlock in open error path that would call close() and try to grab the already held disc_mutex. Fixes: b9a44bc19f48 ("sierra: driver urb handling improvements") Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 1b6e8ae99c48509b84dd2bef7759fc6bf1610a0b Author: Dennis Dalessandro Date: Fri May 2 11:40:17 2014 -0400 IB/ipath: Translate legacy diagpkt into newer extended diagpkt commit 7e6d3e5c70f13874fb06e6b67696ed90ce79bd48 upstream. This patch addresses an issue where the legacy diagpacket is sent in from the user, but the driver operates on only the extended diagpkt. This patch specifically initializes the extended diagpkt based on the legacy packet. Reported-by: Rickard Strandqvist Reviewed-by: Mike Marciniszyn Signed-off-by: Dennis Dalessandro Signed-off-by: Roland Dreier Signed-off-by: Ben Hutchings commit 1338f0894359c5085e34a2733e0d8f1c188485b8 Author: Mike Marciniszyn Date: Fri May 2 11:28:04 2014 -0400 IB/qib: Fix port in pkey change event commit 911eccd284d13d78c92ec4f1f1092c03457d732a upstream. The code used a literal 1 in dispatching an IB_EVENT_PKEY_CHANGE. As of the dual port qib QDR card, this is not necessarily correct. Change to use the port as specified in the call. Reported-by: Alex Estrin Reviewed-by: Dennis Dalessandro Signed-off-by: Mike Marciniszyn Signed-off-by: Roland Dreier Signed-off-by: Ben Hutchings commit 2b3169d262706a577fe4ffdaaad7599cb529d3e1 Author: Maurizio Lombardi Date: Tue May 27 12:48:56 2014 -0400 ext4: fix wrong assert in ext4_mb_normalize_request() commit b5b60778558cafad17bbcbf63e0310bd3c68eb17 upstream. The variable "size" is expressed as number of blocks and not as number of clusters, this could trigger a kernel panic when using ext4 with the size of a cluster different from the size of a block. Signed-off-by: Maurizio Lombardi Signed-off-by: Theodore Ts'o Signed-off-by: Ben Hutchings commit 69c9183261e692f6901de00b5e7024a58d69849c Author: Jan Kara Date: Tue May 27 12:48:55 2014 -0400 ext4: fix zeroing of page during writeback commit eeece469dedadf3918bad50ad80f4616a0064e90 upstream. Tail of a page straddling inode size must be zeroed when being written out due to POSIX requirement that modifications of mmaped page beyond inode size must not be written to the file. ext4_bio_write_page() did this only for blocks fully beyond inode size but didn't properly zero blocks partially beyond inode size. Fix this. The problem has been uncovered by mmap_11-4 test in openposix test suite (part of LTP). Reported-by: Xiaoguang Wang Fixes: 5a0dc7365c240 Fixes: bd2d0210cf22f Signed-off-by: Jan Kara Signed-off-by: Theodore Ts'o [bwh: Backported to 3.2: - Adjust context - block_end was used instead of block_start + blocksize] Signed-off-by: Ben Hutchings commit 722ee3dc658a8619b5e492944f708ebce04f2cd4 Author: Andreas Schrägle Date: Sat May 24 16:35:43 2014 +0200 ahci: add PCI ID for Marvell 88SE91A0 SATA Controller commit 754a292fe6b08196cb135c03b404444e17de520a upstream. Add support for Marvell Technology Group Ltd. 88SE91A0 SATA 6Gb/s Controller by adding its PCI ID. Signed-off-by: Andreas Schrägle Signed-off-by: Tejun Heo Signed-off-by: Ben Hutchings commit 0984f60dc8ba393d3779257ccdc20f74c9372cbf Author: Chris Wilson Date: Fri May 23 10:45:52 2014 +0100 drm/i915: Only copy back the modified fields to userspace from execbuffer commit 9aab8bff7aa3bee567213ad3c1fdfb217bb980a2 upstream. We only want to modifiy a single field in the userspace view of the execbuffer command buffer, so explicitly change that rather than copy everything back again. This serves two purposes: 1. The single fields are much cheaper to copy (constant size so the copy uses special case code) and much smaller than the whole array. 2. We modify the array for internal use that need to be masked from the user. Note: We need this backported since without it the next bugfix will blow up when userspace recycles batchbuffers and relocations. Signed-off-by: Chris Wilson Cc: Daniel Vetter Signed-off-by: Daniel Vetter [bwh: Backported to 3.2: to_user_ptr() is open-coded] Signed-off-by: Ben Hutchings commit d4e82f5f4228f5a45abadd48a408b3745f61e3f8 Author: Daniel Vetter Date: Tue Jan 31 21:08:14 2012 +0100 drm/i915: s/DRM_ERROR/DRM_DEBUG in i915_gem_execbuffer.c commit ff240199b6a3b0bec5ae9b6d26403dad38e8cb19 upstream. These are all user-trigerable, so tune down their loudness a notch. For some of these we have i-g-t tests (because they prevent newly-discovered bugs), without this patches running the test suite leaves behind a dirty dmesg. Reviewed-by: Chris Wilson Signed-Off-by: Daniel Vetter [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit a398e4147fac72299569e5e0bf4bf3d83b914cb1 Author: Krzysztof Hałasa Date: Mon May 26 14:14:46 2014 +0200 mac80211: fix IBSS join by initializing last_scan_completed commit c7d37a66e345df2fdf1aa7b2c9a6d3d53846ca5b upstream. Without this fix, freshly rebooted Linux creates a new IBSS instead of joining an existing one. Only when jiffies counter overflows after 5 minutes the IBSS can be successfully joined. Signed-off-by: Krzysztof Hałasa [edit commit message slightly] Signed-off-by: Johannes Berg [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit c742f9ad85e6a133d79b14fbbd10e6cd2e0aea28 Author: Hans de Goede Date: Mon May 19 22:52:30 2014 -0700 Input: synaptics - T540p - unify with other LEN0034 models commit 6d396ede224dc596d92d7cab433713536e68916c upstream. The T540p has a touchpad with pnp-id LEN0034, all the models with this pnp-id have the same min/max values, except the T540p where the values are slightly off. Fix them to be identical. This is a preparation patch for simplifying the quirk table. Signed-off-by: Hans de Goede Signed-off-by: Dmitry Torokhov Signed-off-by: Ben Hutchings commit f85743e62e15955caa5da907f5a2b02b351722d3 Author: Andrey Ryabinin Date: Wed May 7 08:07:25 2014 +0100 ARM: 8051/1: put_user: fix possible data corruption in put_user commit 537094b64b229bf3ad146042f83e74cf6abe59df upstream. According to arm procedure call standart r2 register is call-cloberred. So after the result of x expression was put into r2 any following function call in p may overwrite r2. To fix this, the result of p expression must be saved to the temporary variable before the assigment x expression to __r2. Signed-off-by: Andrey Ryabinin Reviewed-by: Nicolas Pitre Signed-off-by: Russell King Signed-off-by: Ben Hutchings commit 502c1d6c3e8bbf4fd9152348ee65c439f37596b8 Author: Alan Stern Date: Fri May 23 10:45:54 2014 -0400 USB: Avoid runtime suspend loops for HCDs that can't handle suspend/resume commit 8ef42ddd9a53b73e6fc3934278710c27f80f324f upstream. Not all host controller drivers have bus-suspend and bus-resume methods. When one doesn't, it will cause problems if runtime PM is enabled in the kernel. The PM core will attempt to suspend the controller's root hub, the suspend will fail because there is no bus-suspend routine, and a -EBUSY error code will be returned to the PM core. This will cause the suspend attempt to be repeated shortly thereafter, in a never-ending loop. Part of the problem is that the original error code -ENOENT gets changed to -EBUSY in usb_runtime_suspend(), on the grounds that the PM core will interpret -ENOENT as meaning that the root hub has gotten into a runtime-PM error state. While this change is appropriate for real USB devices, it's not such a good idea for a root hub. In fact, considering the root hub to be in a runtime-PM error state would not be far from the truth. Therefore this patch updates usb_runtime_suspend() so that it adjusts error codes only for non-root-hub devices. Furthermore, the patch attempts to prevent the problem from occurring in the first place by not enabling runtime PM by default for root hubs whose host controller driver doesn't have bus_suspend and bus_resume methods. Signed-off-by: Alan Stern Reported-by: Will Deacon Tested-by: Will Deacon Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.2: runtime PM is also not supported for USB 3.0 non-root hubs] Signed-off-by: Ben Hutchings commit 6733fc4b7822e896f6a0fae44c92a28e7fc3d77f Author: Mikulas Patocka Date: Thu May 15 06:58:24 2014 -0400 matroxfb: perform a dummy read of M_STATUS commit 972754cfaee94d6e25acf94a497bc0a864d91b7e upstream. I had occasional screen corruption with the matrox framebuffer driver and I found out that the reason for the corruption is that the hardware blitter accesses the videoram while it is being written to. The matrox driver has a macro WaitTillIdle() that should wait until the blitter is idle, but it sometimes doesn't work. I added a dummy read mga_inl(M_STATUS) to WaitTillIdle() to fix the problem. The dummy read will flush the write buffer in the PCI chipset, and the next read of M_STATUS will return the hardware status. Since applying this patch, I had no screen corruption at all. Signed-off-by: Mikulas Patocka Signed-off-by: Tomi Valkeinen [bwh: Backported to 3.2: adjust filename] Signed-off-by: Ben Hutchings commit 5b491d9bb60485ac36a4473d07e5ae9da91a7e08 Author: Emil Goode Date: Mon May 19 15:07:54 2014 +0800 ARM: imx: fix error handling in ipu device registration commit d1d70e5dc2cfa9047bb935c41ba808ebb8135696 upstream. If we fail to allocate struct platform_device pdev we dereference it after the goto label err. This bug was found using coccinelle. Fixes: afa77ef (ARM: mx3: dynamically allocate "ipu-core" devices) Signed-off-by: Emil Goode Acked-by: Uwe Kleine-König Signed-off-by: Shawn Guo Signed-off-by: Olof Johansson [bwh: Backported to 3.2: adjust filename] Signed-off-by: Ben Hutchings commit 4e6efff9b1e11c0e825a025f308a6322ca3241e5 Author: Jeff Mahoney Date: Wed May 21 13:28:07 2014 -0400 reiserfs: call truncate_setsize under tailpack mutex commit 22e7478ddbcb670e33fab72d0bbe7c394c3a2c84 upstream. Prior to commit 0e4f6a791b1e (Fix reiserfs_file_release()), reiserfs truncates serialized on i_mutex. They mostly still do, with the exception of reiserfs_file_release. That blocks out other writers via the tailpack mutex and the inode openers counter adjusted in reiserfs_file_open. However, NFS will call reiserfs_setattr without having called ->open, so we end up with a race when nfs is calling ->setattr while another process is releasing the file. Ultimately, it triggers the BUG_ON(inode->i_size != new_file_size) check in maybe_indirect_to_direct. The solution is to pull the lock into reiserfs_setattr to encompass the truncate_setsize call as well. Signed-off-by: Jeff Mahoney Signed-off-by: Jan Kara Signed-off-by: Ben Hutchings commit f6975fe1d8ca4f40768575a8e7b8360e7fa48a45 Author: Marco Stornelli Date: Sat Dec 15 11:47:31 2012 +0100 reiserfs: drop vmtruncate commit cfac4b47c664e207740880d6492938761c53d74b upstream. Removed vmtruncate Signed-off-by: Marco Stornelli Reviewed-by: Jan Kara Signed-off-by: Al Viro [bwh: Backported to 3.2: adjust filename] Signed-off-by: Ben Hutchings commit dc2f3db587e548df5fd55a8b420e18ac8c11cb8e Author: Bart Van Assche Date: Tue May 20 15:03:49 2014 +0200 IB/srp: Fix a sporadic crash triggered by cable pulling commit 024ca90151f5e4296d30f72c13ff9a075e23c9ec upstream. Avoid that the loops that iterate over the request ring can encounter a pointer to a SCSI command in req->scmnd that is no longer associated with that request. If the function srp_unmap_data() is invoked twice for a SCSI command that is not in flight then that would cause ib_fmr_pool_unmap() to be invoked with an invalid pointer as argument, resulting in a kernel oops. Reported-by: Sagi Grimberg Reference: http://thread.gmane.org/gmane.linux.drivers.rdma/19068/focus=19069 Signed-off-by: Bart Van Assche Reviewed-by: Sagi Grimberg Signed-off-by: Roland Dreier Signed-off-by: Ben Hutchings commit 40b81e0d1a79c4770cc353bea225668a74e1493f Author: Kees Cook Date: Thu Apr 17 13:22:09 2014 -0700 HID: core: fix validation of report id 0 commit 1b15d2e5b8077670b1e6a33250a0d9577efff4a5 upstream. Some drivers use the first HID report in the list instead of using an index. In these cases, validation uses ID 0, which was supposed to mean "first known report". This fixes the problem, which was causing at least the lgff family of devices to stop working since hid_validate_values was being called with ID 0, but the devices used single numbered IDs for their reports: 0x05, 0x01, /* Usage Page (Desktop), */ 0x09, 0x05, /* Usage (Gamepad), */ 0xA1, 0x01, /* Collection (Application), */ 0xA1, 0x02, /* Collection (Logical), */ 0x85, 0x01, /* Report ID (1), */ ... Reported-by: Simon Wood Signed-off-by: Kees Cook Reviewed-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Ben Hutchings commit 164b63e6a46aae261210faf970f6f04cf512adf5 Author: Lv Zheng Date: Mon May 12 15:50:16 2014 +0800 ACPI: Fix conflict between customized DSDT and DSDT local copy commit 73577d1df8e1f31f6b1a5eebcdbc334eb0330e47 upstream. This patch fixes the following issue: If DSDT is customized, no local DSDT copy is needed. References: https://bugzilla.kernel.org/show_bug.cgi?id=69711 Signed-off-by: Enrico Etxe Arte Signed-off-by: Lv Zheng [rjw: Subject] Signed-off-by: Rafael J. Wysocki Signed-off-by: Ben Hutchings commit 8a5f808119565bdb8c48c897d5e626f5d7bfb122 Author: Hans de Goede Date: Wed May 14 11:10:40 2014 -0700 Input: synaptics - add min/max quirk for the ThinkPad W540 commit 0b5fe736fe923f1f5e05413878d5990e92ffbdf5 upstream. https://bugzilla.redhat.com/show_bug.cgi?id=1096436 Tested-and-reported-by: ajayr@bigfoot.com Signed-off-by: Hans de Goede Signed-off-by: Dmitry Torokhov Signed-off-by: Ben Hutchings commit 2e87c9895d55ef1df895b766d207f52da391680e Author: hujianyang Date: Wed Apr 30 14:06:06 2014 +0800 UBIFS: fix an mmap and fsync race condition commit 691a7c6f28ac90cccd0dbcf81348ea90b211bdd0 upstream. There is a race condition in UBIFS: Thread A (mmap) Thread B (fsync) ->__do_fault ->write_cache_pages -> ubifs_vm_page_mkwrite -> budget_space -> lock_page -> release/convert_page_budget -> SetPagePrivate -> TestSetPageDirty -> unlock_page -> lock_page -> TestClearPageDirty -> ubifs_writepage -> do_writepage -> release_budget -> ClearPagePrivate -> unlock_page -> !(ret & VM_FAULT_LOCKED) -> lock_page -> set_page_dirty -> ubifs_set_page_dirty -> TestSetPageDirty (set page dirty without budgeting) -> unlock_page This leads to situation where we have a diry page but no budget allocated for this page, so further write-back may fail with -ENOSPC. In this fix we return from page_mkwrite without performing unlock_page. We return VM_FAULT_LOCKED instead. After doing this, the race above will not happen. Signed-off-by: hujianyang Tested-by: Laurence Withers Signed-off-by: Artem Bityutskiy [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 00ff92c2da9ed2bba1f1df324129e7767eeda63a Author: Thomas Gleixner Date: Thu Mar 7 14:53:45 2013 +0100 genirq: Sanitize spurious interrupt detection of threaded irqs commit 1e77d0a1ed7417d2a5a52a7b8d32aea1833faa6c upstream. Till reported that the spurious interrupt detection of threaded interrupts is broken in two ways: - note_interrupt() is called for each action thread of a shared interrupt line. That's wrong as we are only interested whether none of the device drivers felt responsible for the interrupt, but by calling multiple times for a single interrupt line we account IRQ_NONE even if one of the drivers felt responsible. - note_interrupt() when called from the thread handler is not serialized. That leaves the members of irq_desc which are used for the spurious detection unprotected. To solve this we need to defer the spurious detection of a threaded interrupt to the next hardware interrupt context where we have implicit serialization. If note_interrupt is called with action_ret == IRQ_WAKE_THREAD, we check whether the previous interrupt requested a deferred check. If not, we request a deferred check for the next hardware interrupt and return. If set, we check whether one of the interrupt threads signaled success. Depending on this information we feed the result into the spurious detector. If one primary handler of a shared interrupt returns IRQ_HANDLED we disable the deferred check of irq threads on the same line, as we have found at least one device driver who cared. Reported-by: Till Straumann Signed-off-by: Thomas Gleixner Tested-by: Austin Schuh Cc: Oliver Hartkopp Cc: Wolfgang Grandegger Cc: Pavel Pisa Cc: Marc Kleine-Budde Cc: linux-can@vger.kernel.org Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1303071450130.22263@ionos [bwh: Backported to 3.2: adjust context, indentation] Signed-off-by: Ben Hutchings commit 87520218746b8d973670e37237666f174590898c 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 [bwh: Backported to 3.2: adjust context, indentation] Signed-off-by: Ben Hutchings commit 0efda016ac2fb3db57ee19f5df746eca4250955d Author: Will Deacon Date: Fri Nov 16 14:15:00 2012 -0800 mm: highmem: don't treat PKMAP_ADDR(LAST_PKMAP) as a highmem address commit 498c2280212327858e521e9d21345d4cc2637f54 upstream. kmap_to_page returns the corresponding struct page for a virtual address of an arbitrary mapping. This works by checking whether the address falls in the pkmap region and using the pkmap page tables instead of the linear mapping if appropriate. Unfortunately, the bounds checking means that PKMAP_ADDR(LAST_PKMAP) is incorrectly treated as a highmem address and we can end up walking off the end of pkmap_page_table and subsequently passing junk to pte_page. This patch fixes the bound check to stay within the pkmap tables. Signed-off-by: Will Deacon Cc: Mel Gorman Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings