commit c2d6598eefba9cbe5ca69ab6ca59e31f797169ac Author: Greg Kroah-Hartman Date: Thu Jan 29 17:41:03 2015 -0800 Linux 3.18.5 commit 47e4434d89fe19b883b37efd70f5f4fe44f495fc Author: Mathias Krause Date: Sun Jan 11 18:17:42 2015 +0100 crypto: add missing crypto module aliases commit 3e14dcf7cb80b34a1f38b55bc96f02d23fdaaaaf upstream. Commit 5d26a105b5a7 ("crypto: prefix module autoloading with "crypto-"") changed the automatic module loading when requesting crypto algorithms to prefix all module requests with "crypto-". This requires all crypto modules to have a crypto specific module alias even if their file name would otherwise match the requested crypto algorithm. Even though commit 5d26a105b5a7 added those aliases for a vast amount of modules, it was missing a few. Add the required MODULE_ALIAS_CRYPTO annotations to those files to make them get loaded automatically, again. This fixes, e.g., requesting 'ecb(blowfish-generic)', which used to work with kernels v3.18 and below. Also change MODULE_ALIAS() lines to MODULE_ALIAS_CRYPTO(). The former won't work for crypto modules any more. Fixes: 5d26a105b5a7 ("crypto: prefix module autoloading with "crypto-"") Cc: Kees Cook Signed-off-by: Mathias Krause Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit acc5ccb9fe1c1d3840d49e181ae30b924cfc28b5 Author: Kees Cook Date: Mon Nov 24 16:32:38 2014 -0800 crypto: include crypto- module prefix in template commit 4943ba16bbc2db05115707b3ff7b4874e9e3c560 upstream. This adds the module loading prefix "crypto-" to the template lookup as well. For example, attempting to load 'vfat(blowfish)' via AF_ALG now correctly includes the "crypto-" prefix at every level, correctly rejecting "vfat": net-pf-38 algif-hash crypto-vfat(blowfish) crypto-vfat(blowfish)-all crypto-vfat Reported-by: Mathias Krause Signed-off-by: Kees Cook Acked-by: Mathias Krause Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit f2efa8653bb59eeaa47036222bf4dd9acc83aabf Author: Kees Cook Date: Thu Nov 20 17:05:53 2014 -0800 crypto: prefix module autoloading with "crypto-" commit 5d26a105b5a73e5635eae0629b42fa0a90e07b7b upstream. This prefixes all crypto module loading with "crypto-" so we never run the risk of exposing module auto-loading to userspace via a crypto API, as demonstrated by Mathias Krause: https://lkml.org/lkml/2013/3/4/70 Signed-off-by: Kees Cook Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit c4302b5e47006d41c49ed10e66cea583658672e1 Author: Rafael J. Wysocki Date: Fri Dec 12 22:51:58 2014 +0100 ACPI / PM: Do not disable wakeup GPEs that have not been enabled commit 175f8e2650f7ca6b33d338be3ccc1c00e89594ea upstream. In some cases acpi_device_wakeup() may be called to ensure wakeup power to be off for a given device even though that device's wakeup GPE has not been enabled so far. It calls acpi_disable_gpe() on a GPE that's not enabled and this causes ACPICA to return the AE_LIMIT status code from that call which then is reported as an error by the ACPICA's debug facilities (if enabled). This may lead to a fair amount of confusion, so introduce a new ACPI device wakeup flag to store the wakeup GPE status and avoid disabling wakeup GPEs that have not been enabled. Reported-and-tested-by: Venkat Raghavulu Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 11ba6ba933eacf6fdeb9669c6befa686250d7a36 Author: David Spinadel Date: Tue Dec 23 14:38:09 2014 +0200 iwlwifi: mvm: add a flag to enable match found notification commit 7e2a38831db4cf082aa8b4997f3cbfe8cb03b669 upstream. Add a flag that enables match found notification to align with FW API change. Signed-off-by: David Spinadel Signed-off-by: Emmanuel Grumbach Signed-off-by: Greg Kroah-Hartman commit 840b131125d65757015dbe5d97d320654cf3da86 Author: David Vrabel Date: Wed Dec 10 14:48:43 2014 +0000 Revert "swiotlb-xen: pass dev_addr to swiotlb_tbl_unmap_single" commit dbdd74763f1faf799fbb9ed30423182e92919378 upstream. This reverts commit 2c3fc8d26dd09b9d7069687eead849ee81c78e46. This commit broke on x86 PV because entries in the generic SWIOTLB are indexed using (pseudo-)physical address not DMA address and these are not the same in a x86 PV guest. Signed-off-by: David Vrabel Reviewed-by: Stefano Stabellini Signed-off-by: Greg Kroah-Hartman commit 34be58049a912ddde6c9f8827b556935e2ac51a6 Author: Dan Carpenter Date: Sat Dec 6 16:49:24 2014 +0300 ipvs: uninitialized data with IP_VS_IPV6 commit 3b05ac3824ed9648c0d9c02d51d9b54e4e7e874f upstream. The app_tcp_pkt_out() function expects "*diff" to be set and ends up using uninitialized data if CONFIG_IP_VS_IPV6 is turned on. The same issue is there in app_tcp_pkt_in(). Thanks to Julian Anastasov for noticing that. Signed-off-by: Dan Carpenter Acked-by: Julian Anastasov Signed-off-by: Simon Horman Signed-off-by: Greg Kroah-Hartman commit 4270214a955aa60b1547391870b003e15f21b220 Author: Pablo Neira Ayuso Date: Tue Nov 25 00:14:47 2014 +0100 netfilter: conntrack: fix race between confirmation and flush commit 8ca3f5e974f2b4b7f711589f4abff920db36637a upstream. Commit 5195c14c8b27c ("netfilter: conntrack: fix race in __nf_conntrack_confirm against get_next_corpse") aimed to resolve the race condition between the confirmation (packet path) and the flush command (from control plane). However, it introduced a crash when several packets race to add a new conntrack, which seems easier to reproduce when nf_queue is in place. Fix this race, in __nf_conntrack_confirm(), by removing the CT from unconfirmed list before checking the DYING bit. In case race occured, re-add the CT to the dying list This patch also changes the verdict from NF_ACCEPT to NF_DROP when we lose race. Basically, the confirmation happens for the first packet that we see in a flow. If you just invoked conntrack -F once (which should be the common case), then this is likely to be the first packet of the flow (unless you already called flush anytime soon in the past). This should be hard to trigger, but better drop this packet, otherwise we leave things in inconsistent state since the destination will likely reply to this packet, but it will find no conntrack, unless the origin retransmits. The change of the verdict has been discussed in: https://www.marc.info/?l=linux-netdev&m=141588039530056&w=2 Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 9eed1585b50df5c909579c43637bda2d088019ee Author: Pablo Neira Ayuso Date: Sun Jan 4 15:20:41 2015 +0100 netfilter: nfnetlink: relax strict multicast group check from netlink_bind commit 62924af247e95de7041a6d6f2d06cdd05152e2dc upstream. Relax the checking that was introduced in 97840cb ("netfilter: nfnetlink: fix insufficient validation in nfnetlink_bind") when the subscription bitmask is used. Existing userspace code code may request to listen to all of the existing netlink groups by setting an all to one subscription group bitmask. Netlink already validates subscription via setsockopt() for us. Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 436322eeda54e4c8ebb09c7a293dc169afeabb7a Author: Pablo Neira Ayuso Date: Sun Jan 4 15:14:22 2015 +0100 netfilter: nf_tables: fix flush ruleset chain dependencies commit a2f18db0c68fec96631c10cad9384c196e9008ac upstream. Jumping between chains doesn't mix well with flush ruleset. Rules from a different chain and set elements may still refer to us. [ 353.373791] ------------[ cut here ]------------ [ 353.373845] kernel BUG at net/netfilter/nf_tables_api.c:1159! [ 353.373896] invalid opcode: 0000 [#1] SMP [ 353.373942] Modules linked in: intel_powerclamp uas iwldvm iwlwifi [ 353.374017] CPU: 0 PID: 6445 Comm: 31c3.nft Not tainted 3.18.0 #98 [ 353.374069] Hardware name: LENOVO 5129CTO/5129CTO, BIOS 6QET47WW (1.17 ) 07/14/2010 [...] [ 353.375018] Call Trace: [ 353.375046] [] ? nf_tables_commit+0x381/0x540 [ 353.375101] [] nfnetlink_rcv+0x3d8/0x4b0 [ 353.375150] [] netlink_unicast+0x105/0x1a0 [ 353.375200] [] netlink_sendmsg+0x32e/0x790 [ 353.375253] [] sock_sendmsg+0x8e/0xc0 [ 353.375300] [] ? move_addr_to_kernel.part.20+0x19/0x70 [ 353.375357] [] ? move_addr_to_kernel+0x19/0x30 [ 353.375410] [] ? verify_iovec+0x42/0xd0 [ 353.375459] [] ___sys_sendmsg+0x3f0/0x400 [ 353.375510] [] ? native_sched_clock+0x2a/0x90 [ 353.375563] [] ? acct_account_cputime+0x17/0x20 [ 353.375616] [] ? account_user_time+0x88/0xa0 [ 353.375667] [] __sys_sendmsg+0x3d/0x80 [ 353.375719] [] ? int_check_syscall_exit_work+0x34/0x3d [ 353.375776] [] SyS_sendmsg+0xd/0x20 [ 353.375823] [] system_call_fastpath+0x16/0x1b Release objects in this order: rules -> sets -> chains -> tables, to make sure no references to chains are held anymore. Reported-by: Asbjoern Sloth Toennesen Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 7266a6b028384bec87fe23128266f00589580f74 Author: Pablo Neira Ayuso Date: Sun Jan 4 15:20:29 2015 +0100 netfilter: nfnetlink: validate nfnetlink header from batch commit 9ea2aa8b7dba9e99544c4187cc298face254569f upstream. Make sure there is enough room for the nfnetlink header in the netlink messages that are part of the batch. There is a similar check in netlink_rcv_skb(). Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 513c66820333a2cc7b54eaa6a7b5c34f6ffaf770 Author: Michal Hocko Date: Mon Dec 29 20:30:35 2014 +0100 mm: get rid of radix tree gfp mask for pagecache_get_page commit 45f87de57f8fad59302fd263dd81ffa4843b5b24 upstream. Commit 2457aec63745 ("mm: non-atomically mark page accessed during page cache allocation where possible") has added a separate parameter for specifying gfp mask for radix tree allocations. Not only this is less than optimal from the API point of view because it is error prone, it is also buggy currently because grab_cache_page_write_begin is using GFP_KERNEL for radix tree and if fgp_flags doesn't contain FGP_NOFS (mostly controlled by fs by AOP_FLAG_NOFS flag) but the mapping_gfp_mask has __GFP_FS cleared then the radix tree allocation wouldn't obey the restriction and might recurse into filesystem and cause deadlocks. This is the case for most filesystems unfortunately because only ext4 and gfs2 are using AOP_FLAG_NOFS. Let's simply remove radix_gfp_mask parameter because the allocation context is same for both page cache and for the radix tree. Just make sure that the radix tree gets only the sane subset of the mask (e.g. do not pass __GFP_WRITE). Long term it is more preferable to convert remaining users of AOP_FLAG_NOFS to use mapping_gfp_mask instead and simplify this interface even further. Reported-by: Dave Chinner Signed-off-by: Michal Hocko Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 8326fa8ec22f770a900bfe869e7ced22fd42f3e8 Author: Sasha Levin Date: Mon Dec 29 09:39:01 2014 -0500 KEYS: close race between key lookup and freeing commit a3a8784454692dd72e5d5d34dcdab17b4420e74c upstream. When a key is being garbage collected, it's key->user would get put before the ->destroy() callback is called, where the key is removed from it's respective tracking structures. This leaves a key hanging in a semi-invalid state which leaves a window open for a different task to try an access key->user. An example is find_keyring_by_name() which would dereference key->user for a key that is in the process of being garbage collected (where key->user was freed but ->destroy() wasn't called yet - so it's still present in the linked list). This would cause either a panic, or corrupt memory. Fixes CVE-2014-9529. Signed-off-by: Sasha Levin Signed-off-by: David Howells Signed-off-by: Greg Kroah-Hartman commit 101e595b88fc99e3cd5d205dda5ddf944c55ab89 Author: Suman Tripathi Date: Mon Dec 29 08:52:46 2014 +0530 ahci_xgene: Fix the endianess issue in APM X-Gene SoC AHCI SATA controller driver. commit 5c0b8e0de76a86edb99e46612fd9d341b4c4fa0a upstream. This patch fixes the big endian mode issue with function xgene_ahci_read_id. Signed-off-by: Suman Tripathi Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 55f8b818e578c819f4aaea7a5f5da58aa98c5e80 Author: Andy Shevchenko Date: Wed Jan 7 15:24:19 2015 +0200 sata_dwc_460ex: fix resource leak on error path commit 4aaa71873ddb9faf4b0c4826579e2f6d18ff9ab4 upstream. DMA mapped IO should be unmapped on the error path in probe() and unconditionally on remove(). Fixes: 62936009f35a ([libata] Add 460EX on-chip SATA driver, sata_dwc_460ex) Signed-off-by: Andy Shevchenko Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 990785dcf5f47148bd92b312179be5e8404dd727 Author: Bryan O'Donoghue Date: Thu Jan 22 22:58:49 2015 +0000 x86/apic: Re-enable PCI_MSI support for non-SMP X86_32 commit 38a1dfda8e77d7ba74c94d06d8bc41ba98a4bc8c upstream. Commit 0dbc6078c06bc0 ('x86, build, pci: Fix PCI_MSI build on !SMP') introduced the dependency that X86_UP_APIC is only available when PCI_MSI is false. This effectively prevents PCI_MSI support on 32bit UP systems because it disables both APIC and IO-APIC. But APIC support is architecturally required for PCI_MSI. The intention of the patch was to enforce APIC support when PCI_MSI is enabled, but failed to do so. Remove the !PCI_MSI dependency from X86_UP_APIC and enforce X86_UP_APIC when PCI_MSI support is enabled on 32bit UP systems. [ tglx: Massaged changelog ] Fixes 0dbc6078c06bc0 'x86, build, pci: Fix PCI_MSI build on !SMP' Signed-off-by: Bryan O'Donoghue Suggested-by: Thomas Gleixner Reviewed-by: Andy Shevchenko Cc: Thomas Petazzoni Link: http://lkml.kernel.org/r/1421967529-9037-1-git-send-email-pure.logic@nexus-software.ie Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 7b6b3d67f0d7d67426da74611698a74ffb33bea7 Author: Andy Lutomirski Date: Thu Jan 22 11:27:59 2015 -0800 x86, tls: Interpret an all-zero struct user_desc as "no segment" commit 3669ef9fa7d35f573ec9c0e0341b29251c2734a7 upstream. The Witcher 2 did something like this to allocate a TLS segment index: struct user_desc u_info; bzero(&u_info, sizeof(u_info)); u_info.entry_number = (uint32_t)-1; syscall(SYS_set_thread_area, &u_info); Strictly speaking, this code was never correct. It should have set read_exec_only and seg_not_present to 1 to indicate that it wanted to find a free slot without putting anything there, or it should have put something sensible in the TLS slot if it wanted to allocate a TLS entry for real. The actual effect of this code was to allocate a bogus segment that could be used to exploit espfix. The set_thread_area hardening patches changed the behavior, causing set_thread_area to return -EINVAL and crashing the game. This changes set_thread_area to interpret this as a request to find a free slot and to leave it empty, which isn't *quite* what the game expects but should be close enough to keep it working. In particular, using the code above to allocate two segments will allocate the same segment both times. According to FrostbittenKing on Github, this fixes The Witcher 2. If this somehow still causes problems, we could instead allocate a limit==0 32-bit data segment, but that seems rather ugly to me. Fixes: 41bdc78544b8 x86/tls: Validate TLS entries to protect espfix Signed-off-by: Andy Lutomirski Cc: torvalds@linux-foundation.org Link: http://lkml.kernel.org/r/0cb251abe1ff0958b8e468a9a9a905b80ae3a746.1421954363.git.luto@amacapital.net Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit e3b3b6d580b073a5fbf9b74495a88eb9f69bb23c Author: Andy Lutomirski Date: Thu Jan 22 11:27:58 2015 -0800 x86, tls, ldt: Stop checking lm in LDT_empty commit e30ab185c490e9a9381385529e0fd32f0a399495 upstream. 32-bit programs don't have an lm bit in their ABI, so they can't reliably cause LDT_empty to return true without resorting to memset. They shouldn't need to do this. This should fix a longstanding, if minor, issue in all 64-bit kernels as well as a potential regression in the TLS hardening code. Fixes: 41bdc78544b8 x86/tls: Validate TLS entries to protect espfix Signed-off-by: Andy Lutomirski Cc: torvalds@linux-foundation.org Link: http://lkml.kernel.org/r/72a059de55e86ad5e2935c80aa91880ddf19d07c.1421954363.git.luto@amacapital.net Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit f84d9d8d9b3b03b4e449b7c40f99ddacb6d189ad Author: Nadav Amit Date: Thu Jan 8 11:59:03 2015 +0100 KVM: x86: Fix of previously incomplete fix for CVE-2014-8480 commit 63ea0a49ae0b145b91ff2b070c01b66fc75854b9 upstream. STR and SLDT with rip-relative operand can cause a host kernel oops. Mark them as DstMem as well. Signed-off-by: Nadav Amit Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit cb2567bf3eed3c7fe5fd914d827e3088d21e565f Author: Nadav Amit Date: Thu Jan 1 23:11:11 2015 +0200 KVM: x86: SYSENTER emulation is broken commit f3747379accba8e95d70cec0eae0582c8c182050 upstream. SYSENTER emulation is broken in several ways: 1. It misses the case of 16-bit code segments completely (CVE-2015-0239). 2. MSR_IA32_SYSENTER_CS is checked in 64-bit mode incorrectly (bits 0 and 1 can still be set without causing #GP). 3. MSR_IA32_SYSENTER_EIP and MSR_IA32_SYSENTER_ESP are not masked in legacy-mode. 4. There is some unneeded code. Fix it. Signed-off-by: Nadav Amit Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit c546e47591d7c8b4fa3dc2d9dae14c127f0c3b22 Author: Kees Cook Date: Thu Jan 15 16:51:46 2015 -0800 x86, boot: Skip relocs when load address unchanged commit f285f4a21c3253887caceed493089ece17579d59 upstream. On 64-bit, relocation is not required unless the load address gets changed. Without this, relocations do unexpected things when the kernel is above 4G. Reported-by: Baoquan He Signed-off-by: Kees Cook Tested-by: Thomas D. Cc: Vivek Goyal Cc: Jan Beulich Cc: Junjie Mao Cc: Andi Kleen Link: http://lkml.kernel.org/r/20150116005146.GA4212@www.outflux.net Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 056ad39c15c36bc5ce8ede2ae4db45b44181a6d4 Author: Alexandre Demers Date: Tue Dec 9 01:27:50 2014 -0500 x86/tsc: Change Fast TSC calibration failed from error to info commit 520452172e6b318f3a8bd9d4fe1e25066393de25 upstream. Many users see this message when booting without knowning that it is of no importance and that TSC calibration may have succeeded by another way. As explained by Paul Bolle in http://lkml.kernel.org/r/1348488259.1436.22.camel@x61.thuisdomein "Fast TSC calibration failed" should not be considered as an error since other calibration methods are being tried afterward. At most, those send a warning if they fail (not an error). So let's change the message from error to warning. [ tglx: Make if pr_info. It's really not important at all ] Fixes: c767a54ba065 x86/debug: Add KERN_ to bare printks, convert printks to pr_ Signed-off-by: Alexandre Demers Link: http://lkml.kernel.org/r/1418106470-6906-1-git-send-email-alexandre.f.demers@gmail.com Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 246b625243c5e2889e97098662ec069f1ebcac9d Author: K. Y. Srinivasan Date: Mon Jan 12 16:26:02 2015 -0800 x86, hyperv: Mark the Hyper-V clocksource as being continuous commit 32c6590d126836a062b3140ed52d898507987017 upstream. The Hyper-V clocksource is continuous; mark it accordingly. Signed-off-by: K. Y. Srinivasan Acked-by: jasowang@redhat.com Cc: gregkh@linuxfoundation.org Cc: devel@linuxdriverproject.org Cc: olaf@aepfle.de Cc: apw@canonical.com Link: http://lkml.kernel.org/r/1421108762-3331-1-git-send-email-kys@microsoft.com Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit ec987a13d5ec90d690a52304224d731881544f86 Author: Tobias Jakobi Date: Wed Oct 22 03:37:08 2014 +0200 clocksource: exynos_mct: Fix bitmask regression for exynos4_mct_write commit 8c38d28ba8da98f7102c31d35359b4dbe9d1f329 upstream. EXYNOS4_MCT_L_MASK is defined as 0xffffff00, so applying this bitmask produces a number outside the range 0x00 to 0xff, which always results in execution of the default switch statement. Obviously this is wrong and git history shows that the bitmask inversion was incorrectly set during a refactoring of the MCT code. Fix this by putting the inversion at the correct position again. Acked-by: Kukjin Kim Reported-by: GP Orcullo Reviewed-by: Doug Anderson Signed-off-by: Tobias Jakobi Signed-off-by: Daniel Lezcano Signed-off-by: Greg Kroah-Hartman commit 89a2e6efe29a525665a94ace4a40bf2e6aa90885 Author: Jan Beulich Date: Fri Jan 16 15:47:07 2015 +0000 x86, irq: Properly tag virtualization entry in /proc/interrupts commit 4a0d3107d6b19125f21172c2b7d95f9c30ecaf6f upstream. The mis-naming likely was a copy-and-paste effect. Signed-off-by: Jan Beulich Link: http://lkml.kernel.org/r/54B9408B0200007800055E8B@mail.emea.novell.com Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 449af2873ea16ef0da68bf64dcef78048d4427d1 Author: Gavin Li Date: Tue Jan 6 18:47:23 2015 -0800 irqchip: atmel-aic-common: Prevent clobbering of priority when changing IRQ type commit 91d1179212161f220938198b742c328ad38fd0a3 upstream. This patch makes the bitmask for AIC_SRCTYPE consistent with that of its valid values, and prevents the priority field at bits 2:0 from being clobbered by an incorrect AND with the AIC_SRCTYPE mask. Signed-off-by: Gavin Li Acked-by: Boris Brezillon Acked-by: Nicolas Ferre Link: https://lkml.kernel.org/r/1420598843-8409-1-git-send-email-gavinli@thegavinli.com Signed-off-by: Jason Cooper Signed-off-by: Greg Kroah-Hartman commit 24f1a316c4bfeed2e1d9a7803545839e2d2e4a0b Author: Al Viro Date: Sun Jan 18 23:37:32 2015 -0500 fix deadlock in cifs_ioctl_clone() commit 378ff1a53b5724f3ac97b0aba3c9ecac072f6fcd upstream. It really needs to check that src is non-directory *and* use {un,}lock_two_nodirectories(). As it is, it's trivial to cause double-lock (ioctl(fd, CIFS_IOC_COPYCHUNK_FILE, fd)) and if the last argument is an fd of directory, we are asking for trouble by violating the locking order - all directories go before all non-directories. If the last argument is an fd of parent directory, it has 50% odds of locking child before parent, which will cause AB-BA deadlock if we race with unlink(). Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 3436c0aadcc5827fcce5ef3b33d4d523720f7137 Author: Andrew Lunn Date: Sun Jan 18 09:46:10 2015 -0600 bus: mvebu-mbus: fix support of MBus window 13 commit 38bdf45f4aa5cb6186d50a29e6cbbd9d486a1519 upstream. On Armada XP, 375 and 38x the MBus window 13 has the remap capability, like windows 0 to 7. However, the mvebu-mbus driver isn't currently taking into account this special case, which means that when window 13 is actually used, the remap registers are left to 0, making the device using this MBus window unavailable. As a minimal fix for stable, don't use window 13. A full fix will follow later. Fixes: fddddb52a6c ("bus: introduce an Marvell EBU MBus driver") Reviewed-by: Thomas Petazzoni Signed-off-by: Andrew Lunn Signed-off-by: Greg Kroah-Hartman commit 1f20756ce695ee56c2899e95757497d9c1cc8bbb Author: Thomas Petazzoni Date: Fri Jan 16 17:11:27 2015 +0100 ARM: mvebu: completely disable hardware I/O coherency commit 8f1e8ee28660018a935c7576b9af8ffe1feab54c upstream. The current hardware I/O coherency is known to cause problems with DMA coherent buffers, as it still requires explicit I/O synchronization barriers, which is not compatible with the semantics expected by the Linux DMA coherent buffers API. So, in order to have enough time to validate a new solution based on automatic I/O synchronization barriers, this commit disables hardware I/O coherency entirely. Future patches will re-enable it. Signed-off-by: Thomas Petazzoni Signed-off-by: Andrew Lunn Signed-off-by: Greg Kroah-Hartman commit 7b915d382aa74aa03c1a48296dd74e94e0d1345f Author: Fabio Estevam Date: Wed Jan 14 11:11:03 2015 -0200 ARM: dts: imx25: Fix PWM "per" clocks commit 7ecd0bde5bfea524a843ad8fa8cb66ccbce68779 upstream. Currently PWM functionality is broken on mx25 due to the wrong assignment of the PWM "per" clock. According to Documentation/devicetree/bindings/clock/imx25-clock.txt: pwm_ipg_per 52 ,so update the pwm "per" to use 'pwm_ipg_per' instead of 'per10' clock. With this change PWM can work fine on mx25. Reported-by: Carlos Soto Signed-off-by: Fabio Estevam Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit e8e3b6ddd0a6afa267029141946918392b425cf4 Author: Sasha Levin Date: Wed Dec 3 19:25:05 2014 -0500 time: adjtimex: Validate the ADJ_FREQUENCY values commit 5e5aeb4367b450a28f447f6d5ab57d8f2ab16a5f upstream. Verify that the frequency value from userspace is valid and makes sense. Unverified values can cause overflows later on. Cc: Thomas Gleixner Cc: Ingo Molnar Signed-off-by: Sasha Levin [jstultz: Fix up bug for negative values and drop redunent cap check] Signed-off-by: John Stultz Signed-off-by: Greg Kroah-Hartman commit 5f4d5404ee8af904b8e843a7fc21f27ff8e6cb83 Author: Sasha Levin Date: Wed Dec 3 19:22:48 2014 -0500 time: settimeofday: Validate the values of tv from user commit 6ada1fc0e1c4775de0e043e1bd3ae9d065491aa5 upstream. An unvalidated user input is multiplied by a constant, which can result in an undefined behaviour for large values. While this is validated later, we should avoid triggering undefined behaviour. Cc: Thomas Gleixner Cc: Ingo Molnar Signed-off-by: Sasha Levin [jstultz: include trivial milisecond->microsecond correction noticed by Andy] Signed-off-by: John Stultz Signed-off-by: Greg Kroah-Hartman commit cfaa6851b052bc98519e8ba2d5a95bf30ff8ee48 Author: Felipe Balbi Date: Tue Jan 6 14:38:08 2015 -0600 irqchip: omap-intc: Fix legacy DMA regression commit 4b149e417463bbb6d1d9b805f729627ca2b54495 upstream. commit 55601c9f2467 (arm: omap: intc: switch over to linear irq domain) introduced a regression with SDMA legacy driver because that driver strictly depends on INTC's IRQs starting at NR_IRQs. Aparently irq_domain_add_linear() won't guarantee that, since we see a 7 IRQs difference when booting with and without the commit cited above. Until arch/arm/plat-omap/dma.c is properly fixed, we must maintain OMAP2/3 using irq_domain_add_legacy(). A FIXME note was added so people know to delete that code once that legacy DMA driver is fixed up. Fixes: 55601c9f2467 (arm: omap: intc: switch over to linear irq domain) Tested-by: Aaro Koskinen Tested-by: Tony Lindgren Signed-off-by: Felipe Balbi Link: https://lkml.kernel.org/r/1420576688-10604-1-git-send-email-balbi@ti.com Signed-off-by: Jason Cooper Signed-off-by: Greg Kroah-Hartman commit 538c2bc4ec400e9d8eda31246c7537cabc398dd0 Author: Joe Thornber Date: Fri Jan 23 10:16:16 2015 +0000 dm cache: fix problematic dual use of a single migration count variable commit a59db67656021fa212e9b95a583f13c34eb67cd9 upstream. Introduce a new variable to count the number of allocated migration structures. The existing variable cache->nr_migrations became overloaded. It was used to: i) track of the number of migrations in flight for the purposes of quiescing during suspend. ii) to estimate the amount of background IO occuring. Recent discard changes meant that REQ_DISCARD bios are processed with a migration. Discards are not background IO so nr_migrations was not incremented. However this could cause quiescing to complete early. (i) is now handled with a new variable cache->nr_allocated_migrations. cache->nr_migrations has been renamed cache->nr_io_migrations. cleanup_migration() is now called free_io_migration(), since it decrements that variable. Also, remove the unused cache->next_migration variable that got replaced with with prealloc_structs a while ago. Signed-off-by: Joe Thornber Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 7bf9ed7e78a3bd0b6179f13cd4d533b3e3f38ed9 Author: Joe Thornber Date: Fri Jan 23 10:00:07 2015 +0000 dm cache: share cache-metadata object across inactive and active DM tables commit 9b1cc9f251affdd27f29fe46d0989ba76c33faf6 upstream. If a DM table is reloaded with an inactive table when the device is not suspended (normal procedure for LVM2), then there will be two dm-bufio objects that can diverge. This can lead to a situation where the inactive table uses bufio to read metadata at the same time the active table writes metadata -- resulting in the inactive table having stale metadata buffers once it is promoted to the active table slot. Fix this by using reference counting and a global list of cache metadata objects to ensure there is only one metadata object per metadata device. Signed-off-by: Joe Thornber Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 7536e0dce329aabda3f06a0356ac974bcdb42cae Author: Hans Verkuil Date: Mon Jan 19 06:16:18 2015 -0300 vb2: fix vb2_thread_stop race conditions commit 6cf11ee6300f38b7cfc43af9b7be2afaa5e05869 upstream. The locking scheme inside the vb2 thread is unsafe when stopping the thread. In particular kthread_stop was called *after* internal data structures were cleaned up instead of doing that before. In addition, internal vb2 functions were called after threadio->stop was set to true and vb2_internal_streamoff was called. This is also not allowed. All this led to a variety of race conditions and kernel warnings and/or oopses. Fixed by moving the kthread_stop call up before the cleanup takes place, and by checking threadio->stop before calling internal vb2 queuing operations. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 5d9aa9e5e8eb25585367caa034bba3cdc4f59f34 Author: Matthias Schwarzott Date: Mon Dec 22 19:51:39 2014 -0300 cx23885: Split Hauppauge WinTV Starburst from HVR4400 card entry commit 721f3223f26bbe81c7e55f84188e74d99df50a16 upstream. Unconditionally attaching Si2161/Si2165 demod driver breaks Hauppauge WinTV Starburst. So create own card entry for this. Add card name comments to the subsystem ids. This fixes a regression introduced in 3.17 by 36efec48e2e6016e05364906720a0ec350a5d768 ([media] cx23885: Add si2165 support for HVR-5500) Signed-off-by: Matthias Schwarzott Tested-by: Antti Palosaari Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit a2d8617dff910d5afe2964b722d71fc6e1bb1c09 Author: Brian King Date: Thu Oct 30 17:27:10 2014 -0500 ipr: wait for aborted command responses commit 6cdb08172bc89f0a39e1643c5e7eab362692fd1b upstream. Fixes a race condition in abort handling that was injected when multiple interrupt support was added. When only a single interrupt is present, the adapter guarantees it will send responses for aborted commands prior to the response for the abort command itself. With multiple interrupts, these responses generally come back on different interrupts, so we need to ensure the abort thread waits until the aborted command is complete so we don't perform a double completion. This race condition was being hit frequently in environments which were triggering command timeouts, which was resulting in a double completion causing a kernel oops. Signed-off-by: Brian King Reviewed-by: Wendy Xiong Tested-by: Wendy Xiong Signed-off-by: Christoph Hellwig Signed-off-by: Greg Kroah-Hartman commit 587a7ba37c5c1e53731b6b48dcde7b17a682b5ac Author: Alex Williamson Date: Thu Jan 15 18:17:12 2015 -0600 PCI: Mark Atheros AR93xx to avoid bus reset commit c3e59ee4e76686b0c84ca8faa1011d10cd4ca1b8 upstream. Reports against the TL-WDN4800 card indicate that PCI bus reset of this Atheros device cause system lock-ups and resets. I've also been able to confirm this behavior on multiple systems. The device never returns from reset and attempts to access config space of the device after reset result in hangs. Blacklist bus reset for the device to avoid this issue. [bhelgaas: This regression appeared in v3.14. Andreas bisected it to 425c1b223dac ("PCI: Add Virtual Channel to save/restore support"), but we don't understand the mechanism by which that commit affects the reset path.] [bhelgaas: changelog, references] Link: http://lkml.kernel.org/r/20140923210318.498dacbd@dualc.maya.org Reported-by: Andreas Hartmann Tested-by: Andreas Hartmann Signed-off-by: Alex Williamson Signed-off-by: Bjorn Helgaas Signed-off-by: Greg Kroah-Hartman commit b01f14468da12c2e548dc965d522b12d51d4be9b Author: Alex Williamson Date: Thu Jan 15 18:16:04 2015 -0600 PCI: Add flag for devices where we can't use bus reset commit f331a859e0ee5a898c1f47596eddad4c4f02d657 upstream. Enable a mechanism for devices to quirk that they do not behave when doing a PCI bus reset. We require a modest level of spec compliant behavior in order to do a reset, for instance the device should come out of reset without throwing errors and PCI config space should be accessible after reset. This is too much to ask for some devices. Link: http://lkml.kernel.org/r/20140923210318.498dacbd@dualc.maya.org Signed-off-by: Alex Williamson Signed-off-by: Bjorn Helgaas Signed-off-by: Greg Kroah-Hartman commit 33658764e935304bc6b44cfcce3f356ff6c17e57 Author: Yinghai Lu Date: Thu Jan 15 16:21:49 2015 -0600 x86/PCI: Clip bridge windows to fit in upstream windows commit 851b09369255a91e77f56d83e3643439ac5b209a upstream. Every PCI-PCI bridge window should fit inside an upstream bridge window because orphaned address space is unreachable from the primary side of the upstream bridge. If we inherit invalid bridge windows that overlap an upstream window from firmware, clip them to fit and update the bridge accordingly. [bhelgaas: changelog] Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491 Reported-by: Marek Kordik Tested-by: Marek Kordik Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources") Signed-off-by: Yinghai Lu Signed-off-by: Bjorn Helgaas CC: Thomas Gleixner CC: Ingo Molnar CC: "H. Peter Anvin" CC: x86@kernel.org Signed-off-by: Greg Kroah-Hartman commit 73698b0099cccfb7a3782d414ff59df2d1d714b0 Author: Yinghai Lu Date: Thu Jan 15 16:21:49 2015 -0600 PCI: Add pci_bus_clip_resource() to clip to fit upstream window commit 0f7e7aee2f37119a32e6e8b63250922442528961 upstream. Add pci_bus_clip_resource(). If a PCI-PCI bridge window overlaps an upstream bridge window but is not completely contained by it, this clips the downstream window so it fits inside the upstream one. No functional change (this adds the function but no callers). [bhelgaas: changelog, split into separate patch] Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491 Reported-by: Marek Kordik Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources") Signed-off-by: Yinghai Lu Signed-off-by: Bjorn Helgaas Signed-off-by: Greg Kroah-Hartman commit 9f2e98fd131d035096e6754268acf0e1ac2f1f48 Author: Yinghai Lu Date: Thu Jan 15 16:21:49 2015 -0600 PCI: Add pci_claim_bridge_resource() to clip window if necessary commit 8505e729a2f6eb0803ff943a15f133dd10afff3a upstream. Add pci_claim_bridge_resource() to claim a PCI-PCI bridge window. This is like regular pci_claim_resource(), except that if we fail to claim the window, we check to see if we can reduce the size of the window and try again. This is for scenarios like this: pci_bus 0000:00: root bus resource [mem 0xc0000000-0xffffffff] pci 0000:00:01.0: bridge window [mem 0xbdf00000-0xddefffff 64bit pref] pci 0000:01:00.0: reg 0x10: [mem 0xc0000000-0xcfffffff pref] The 00:01.0 window is illegal: it starts before the host bridge window, so we have to assume the [0xbdf00000-0xbfffffff] region is inaccessible. We can make it legal by clipping it to [mem 0xc0000000-0xddefffff 64bit pref]. Previously we discarded the 00:01.0 window and tried to reassign that part of the hierarchy from scratch. That is a problem because Linux doesn't always assign things optimally. For example, in this case, BIOS put the 01:00.0 device in a prefetchable window below 4GB, but after 5b28541552ef, Linux puts the prefetchable window above 4GB where the 32-bit 01:00.0 device can't use it. Clipping the 00:01.0 window is less intrusive than completely reassigning things and is sufficient to let us use most of the BIOS configuration. Of course, it's possible that devices below 00:01.0 will no longer fit. If that's the case, we'll have to reassign things. But that's a separate problem. [bhelgaas: changelog, split into separate patch] Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491 Reported-by: Marek Kordik Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources") Signed-off-by: Yinghai Lu Signed-off-by: Bjorn Helgaas Signed-off-by: Greg Kroah-Hartman commit ad5fa86f4e3380b841cc7ed2dc8ce35401c6045b Author: Yinghai Lu Date: Thu Jan 15 10:22:31 2015 -0600 PCI: Pass bridge device, not bus, when updating bridge windows commit 3f2f4dc456e9f80849b99d79600a7257690ca4b1 upstream. pci_setup_bridge_io(), pci_setup_bridge_mmio(), and pci_setup_bridge_mmio_pref() program the windows of PCI-PCI bridges. Previously they accepted a pointer to the pci_bus of the secondary bus, then looked up the bridge leading to that bus. Pass the bridge directly, which will make it more convenient for future callers. No functional change. [bhelgaas: changelog, split into separate patch] Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491 Reported-by: Marek Kordik Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources") Signed-off-by: Yinghai Lu Signed-off-by: Bjorn Helgaas Signed-off-by: Greg Kroah-Hartman commit d5adda6575beeaa3a0e5076527eabac37bcc4533 Author: Alex Deucher Date: Thu Jan 15 10:52:33 2015 -0500 drm/radeon: use rv515_ring_start on r5xx commit d8a74e186949e1a2c2f1309212478b0659bf9225 upstream. This was accidently lost in 76a0df859def. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit ff32f6aab7dcdba9f65be5268f260c7fcb66d4d6 Author: Alex Deucher Date: Mon Jan 12 17:15:12 2015 -0500 drm/radeon: add si dpm quirk list commit 5615f890bc6babdc2998dec62f3552326d06eb7b upstream. This adds a quirks list to fix stability problems with certain SI boards. bug: https://bugs.freedesktop.org/show_bug.cgi?id=76490 Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 4e77f9fb47c9455be7ef8a2aa23bb3bf54567b2c Author: Alex Deucher Date: Thu Jan 8 10:46:33 2015 -0500 drm/radeon: add a dpm quirk list commit 4369a69ec6ab86821352bd753c68af5880f87956 upstream. Disable dpm on certain problematic boards rather than disabling dpm for the entire chip family since most boards work fine. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1386534 https://bugzilla.kernel.org/show_bug.cgi?id=83731 Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 8dcffdd314b74849a3fa4ca26e0518d5481bdfbe Author: Chris Wilson Date: Fri Jan 2 09:47:10 2015 +0000 drm/i915: Fix mutex->owner inspection race under DEBUG_MUTEXES commit 226e5ae9e5f9108beb0bde4ac69f68fe6210fed9 upstream. If CONFIG_DEBUG_MUTEXES is set, the mutex->owner field is only cleared if the mutex debugging is enabled which introduces a race in our mutex_is_locked_by() - i.e. we may inspect the old owner value before it is acquired by the new task. This is the root cause of this error: # diff --git a/kernel/locking/mutex-debug.c b/kernel/locking/mutex-debug.c # index 5cf6731..3ef3736 100644 # --- a/kernel/locking/mutex-debug.c # +++ b/kernel/locking/mutex-debug.c # @@ -80,13 +80,13 @@ void debug_mutex_unlock(struct mutex *lock) # DEBUG_LOCKS_WARN_ON(lock->owner != current); # # DEBUG_LOCKS_WARN_ON(!lock->wait_list.prev && !lock->wait_list.next); # - mutex_clear_owner(lock); # } # # /* # * __mutex_slowpath_needs_to_unlock() is explicitly 0 for debug # * mutexes so that we can do it here after we've verified state. # */ # + mutex_clear_owner(lock); # atomic_set(&lock->count, 1); # } Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87955 Signed-off-by: Chris Wilson Reviewed-by: Daniel Vetter Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 00647dbf5150fa2f3279d9be534cb06e24d537f4 Author: Chris Wilson Date: Sat Dec 27 09:48:28 2014 +0000 drm/i915: Ban Haswell from using RCS flips commit 48bf5b2d00bfeb681f6500c626189c7cd2c964d2 upstream. Like Ivybridge, we have reports that we get random hangs when flipping with multiple pipes. Extend commit 2a92d5bca1999b69c78f3c3e97b5484985b094b9 Author: Chris Wilson Date: Tue Jul 8 10:40:29 2014 +0100 drm/i915: Disable RCS flips on Ivybridge to also apply to Haswell. Reported-and-tested-by: Scott Tsai Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87759 Signed-off-by: Chris Wilson Reviewed-by: Daniel Vetter Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 7cc613f0d13aac39480c963745c8b94b47b52b8c Author: Michael Karcher Date: Sun Jan 18 00:36:15 2015 +0100 scripts/recordmcount.pl: There is no -m32 gcc option on Super-H anymore commit 1caf6aaaa47471831d77c75f094d4e00ad1ec808 upstream. Compiling SH with gcc-4.8 fails due to the -m32 option not being supported. From http://buildd.debian-ports.org/status/fetch.php?pkg=linux&arch=sh4&ver=3.16.7-ckt4-1&stamp=1421425783 CC init/main.o gcc-4.8: error: unrecognized command line option '-m32' ld: cannot find init/.tmp_mc_main.o: No such file or directory objcopy: 'init/.tmp_mx_main.o': No such file rm: cannot remove 'init/.tmp_mx_main.o': No such file or directory rm: cannot remove 'init/.tmp_mc_main.o': No such file or directory Link: http://lkml.kernel.org/r/1421537778-29001-1-git-send-email-kernel@mkarcher.dialup.fu-berlin.de Link: http://lkml.kernel.org/r/54BCBDD4.10102@physik.fu-berlin.de Cc: Matt Fleming Reported-by: John Paul Adrian Glaubitz Signed-off-by: Michael Karcher Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 8fdd4f779530d6de523b24816bba81b1f8d5766e Author: Tejun Heo Date: Fri Jan 16 14:21:16 2015 -0500 workqueue: fix subtle pool management issue which can stall whole worker_pool commit 29187a9eeaf362d8422e62e17a22a6e115277a49 upstream. A worker_pool's forward progress is guaranteed by the fact that the last idle worker assumes the manager role to create more workers and summon the rescuers if creating workers doesn't succeed in timely manner before proceeding to execute work items. This manager role is implemented in manage_workers(), which indicates whether the worker may proceed to work item execution with its return value. This is necessary because multiple workers may contend for the manager role, and, if there already is a manager, others should proceed to work item execution. Unfortunately, the function also indicates that the worker may proceed to work item execution if need_to_create_worker() is false at the head of the function. need_to_create_worker() tests the following conditions. pending work items && !nr_running && !nr_idle The first and third conditions are protected by pool->lock and thus won't change while holding pool->lock; however, nr_running can change asynchronously as other workers block and resume and while it's likely to be zero, as someone woke this worker up in the first place, some other workers could have become runnable inbetween making it non-zero. If this happens, manage_worker() could return false even with zero nr_idle making the worker, the last idle one, proceed to execute work items. If then all workers of the pool end up blocking on a resource which can only be released by a work item which is pending on that pool, the whole pool can deadlock as there's no one to create more workers or summon the rescuers. This patch fixes the problem by removing the early exit condition from maybe_create_worker() and making manage_workers() return false iff there's already another manager, which ensures that the last worker doesn't start executing work items. We can leave the early exit condition alone and just ignore the return value but the only reason it was put there is because the manage_workers() used to perform both creations and destructions of workers and thus the function may be invoked while the pool is trying to reduce the number of workers. Now that manage_workers() is called only when more workers are needed, the only case this early exit condition is triggered is rare race conditions rendering it pointless. Tested with simulated workload and modified workqueue code which trigger the pool deadlock reliably without this patch. Signed-off-by: Tejun Heo Reported-by: Eric Sandeen Link: http://lkml.kernel.org/g/54B019F4.8030009@sandeen.net Cc: Dave Chinner Cc: Lai Jiangshan Signed-off-by: Greg Kroah-Hartman commit 335b7ac3cd27af924b5a06eae691cd010fad1ae1 Author: Jason Lee Cragg Date: Sat Jan 17 12:28:29 2015 -0500 ALSA: usb-audio: Add mic volume fix quirk for Logitech Webcam C210 commit 6455931186bff407493135e74c5f32efd30860e2 upstream. Signed-off-by: Jason Lee Cragg Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 362a0d61df59fbd7df81c521de30dfc1ffb7bb11 Author: David Jeffery Date: Mon Jan 19 13:03:25 2015 -0600 libata: prevent HSM state change race between ISR and PIO commit ce7514526742c0898b837d4395f515b79dfb5a12 upstream. It is possible for ata_sff_flush_pio_task() to set ap->hsm_task_state to HSM_ST_IDLE in between the time __ata_sff_port_intr() checks for HSM_ST_IDLE and before it calls ata_sff_hsm_move() causing ata_sff_hsm_move() to BUG(). This problem is hard to reproduce making this patch hard to verify, but this fix will prevent the race. I have not been able to reproduce the problem, but here is a crash dump from a 2.6.32 kernel. On examining the ata port's state, its hsm_task_state field has a value of HSM_ST_IDLE: crash> struct ata_port.hsm_task_state ffff881c1121c000 hsm_task_state = 0 Normally, this should not be possible as ata_sff_hsm_move() was called from ata_sff_host_intr(), which checks hsm_task_state and won't call ata_sff_hsm_move() if it has a HSM_ST_IDLE value. PID: 11053 TASK: ffff8816e846cae0 CPU: 0 COMMAND: "sshd" #0 [ffff88008ba03960] machine_kexec at ffffffff81038f3b #1 [ffff88008ba039c0] crash_kexec at ffffffff810c5d92 #2 [ffff88008ba03a90] oops_end at ffffffff8152b510 #3 [ffff88008ba03ac0] die at ffffffff81010e0b #4 [ffff88008ba03af0] do_trap at ffffffff8152ad74 #5 [ffff88008ba03b50] do_invalid_op at ffffffff8100cf95 #6 [ffff88008ba03bf0] invalid_op at ffffffff8100bf9b [exception RIP: ata_sff_hsm_move+317] RIP: ffffffff813a77ad RSP: ffff88008ba03ca0 RFLAGS: 00010097 RAX: 0000000000000000 RBX: ffff881c1121dc60 RCX: 0000000000000000 RDX: ffff881c1121dd10 RSI: ffff881c1121dc60 RDI: ffff881c1121c000 RBP: ffff88008ba03d00 R8: 0000000000000000 R9: 000000000000002e R10: 000000000001003f R11: 000000000000009b R12: ffff881c1121c000 R13: 0000000000000000 R14: 0000000000000050 R15: ffff881c1121dd78 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ffff88008ba03d08] ata_sff_host_intr at ffffffff813a7fbd #8 [ffff88008ba03d38] ata_sff_interrupt at ffffffff813a821e #9 [ffff88008ba03d78] handle_IRQ_event at ffffffff810e6ec0 commit 99bde8fc1cf78bc7fded2d1c52a732fc26a09606 Author: Dan Williams Date: Fri Jan 16 15:13:02 2015 -0800 libata: allow sata_sil24 to opt-out of tag ordered submission commit 72dd299d5039a336493993dcc63413cf31d0e662 upstream. Ronny reports: https://bugzilla.kernel.org/show_bug.cgi?id=87101 "Since commit 8a4aeec8d "libata/ahci: accommodate tag ordered controllers" the access to the harddisk on the first SATA-port is failing on its first access. The access to the harddisk on the second port is working normal. When reverting the above commit, access to both harddisks is working fine again." Maintain tag ordered submission as the default, but allow sata_sil24 to continue with the old behavior. Cc: Tejun Heo Reported-by: Ronny Hegewald Signed-off-by: Dan Williams Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 28de6f351a65d7516f80337d5bc80d3ea948480d Author: Roger Tseng Date: Thu Jan 15 15:14:44 2015 +0800 mfd: rtsx_usb: Fix runtime PM deadlock commit b166010f6afbadb896efa37ff85eb681a8f89392 upstream. sd_set_power_mode() in derived module drivers/mmc/host/rtsx_usb_sdmmc.c acquires dev_mutex and then calls pm_runtime_get_sync() to make sure the device is awake while initializing a newly inserted card. Once it is called during suspending state and explicitly before rtsx_usb_suspend() acquires the same dev_mutex, both routine deadlock and further hang the driver because pm_runtime_get_sync() waits the pending PM operations. Fix this by using an empty suspend method. mmc_core always turns the LED off after a request is done and thus it is ok to remove the only rtsx_usb_turn_off_led() here. Fixes: 730876be2566 ("mfd: Add realtek USB card reader driver") Signed-off-by: Roger Tseng [Lee: Removed newly unused variable] Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit 5a8405ca2159a696b8eb535642505bbe9c4e1328 Author: Felipe Balbi Date: Fri Dec 26 13:28:21 2014 -0600 mfd: tps65218: Make INT1 our status_base register commit f29ae369a412942e81035984fa3d7a22ddf91fcb upstream. If we don't tell regmap-irq that our first status register is at offset 1, it will try to read offset zero, which is the chipid register. Fixes: 44b4dc6 mfd: tps65218: Add driver for the TPS65218 PMIC Signed-off-by: Felipe Balbi Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit fc904760b41b2ae22df59b8757bdf76fd930a86a Author: Felipe Balbi Date: Fri Dec 26 13:28:20 2014 -0600 mfd: tps65218: Make INT[12] and STATUS registers volatile commit 773328da243978bebac82bf4c45604281edb6975 upstream. STATUS register can be modified by the HW, so we should bypass cache because of that. In the case of INT[12] registers, they are the ones that actually clear the IRQ source at the time they are read. If we rely on the cache for them, we will never be able to clear the interrupt, which will cause our IRQ line to be disabled due to IRQ throttling. Fixes: 44b4dc6 mfd: tps65218: Add driver for the TPS65218 PMIC Signed-off-by: Felipe Balbi Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit 515939f381952c805df52c66360dc9453bda2be7 Author: Jim Lin Date: Thu Jan 8 20:25:05 2015 +0800 pinctrl: Fix two deadlocks commit db93facfb0ef542aa5d8079e47580b3e669a4d82 upstream. This patch is to fix two deadlock cases. Deadlock 1: CPU #1 pinctrl_register-> pinctrl_get -> create_pinctrl (Holding lock pinctrl_maps_mutex) -> get_pinctrl_dev_from_devname (Trying to acquire lock pinctrldev_list_mutex) CPU #0 pinctrl_unregister (Holding lock pinctrldev_list_mutex) -> pinctrl_put ->> pinctrl_free -> pinctrl_dt_free_maps -> pinctrl_unregister_map (Trying to acquire lock pinctrl_maps_mutex) Simply to say CPU#1 is holding lock A and trying to acquire lock B, CPU#0 is holding lock B and trying to acquire lock A. Deadlock 2: CPU #3 pinctrl_register-> pinctrl_get -> create_pinctrl (Holding lock pinctrl_maps_mutex) -> get_pinctrl_dev_from_devname (Trying to acquire lock pinctrldev_list_mutex) CPU #2 pinctrl_unregister (Holding lock pctldev->mutex) -> pinctrl_put ->> pinctrl_free -> pinctrl_dt_free_maps -> pinctrl_unregister_map (Trying to acquire lock pinctrl_maps_mutex) CPU #0 tegra_gpio_request (Holding lock pinctrldev_list_mutex) -> pinctrl_get_device_gpio_range (Trying to acquire lock pctldev->mutex) Simply to say CPU#3 is holding lock A and trying to acquire lock D, CPU#2 is holding lock B and trying to acquire lock A, CPU#0 is holding lock D and trying to acquire lock B. Signed-off-by: Jim Lin Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit ce441cb4f15f5d6d7fc509dae6c9e00b56aadb45 Author: Stephen Boyd Date: Mon Jan 19 11:17:45 2015 +0100 pinctrl: qcom: Don't iterate past end of function array commit bcd53f858d87f52843cc87764b283999126a50d6 upstream. Timur reports that this code crashes if nfunctions is 0. Fix the loop iteration to only consider valid elements of the functions array. Reported-by: Timur Tabi Cc: Pramod Gurav Cc: Bjorn Andersson Cc: Ivan T. Ivanov Cc: Andy Gross Fixes: 327455817a92 "pinctrl: qcom: Add support for reset for apq8064" Signed-off-by: Stephen Boyd Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit b47d1db630f022bc88f1085d831ec4aee71a25e6 Author: Oliver Hartkopp Date: Mon Jan 5 19:47:43 2015 +0100 can: m_can: tag current CAN FD controllers as non-ISO commit 6cfda7fbebe8a4fd33ea5722fa0212f98f643c35 upstream. During the CAN FD standardization process within the ISO it turned out that the failure detection capability has to be improved. The CAN in Automation organization (CiA) defined the already implemented CAN FD controllers as 'non-ISO' and the upcoming improved CAN FD controllers as 'ISO' compliant. See at http://www.can-cia.com/index.php?id=1937 Finally there will be three types of CAN FD controllers in the future: 1. ISO compliant (fixed) 2. non-ISO compliant (fixed, like the M_CAN IP v3.0.1 in m_can.c) 3. ISO/non-ISO CAN FD controllers (switchable, like the PEAK USB FD) So the current M_CAN driver for the M_CAN IP v3.0.1 has to expose its non-ISO implementation by setting the CAN_CTRLMODE_FD_NON_ISO ctrlmode at startup. As this bit cannot be switched at configuration time CAN_CTRLMODE_FD_NON_ISO must not be set in ctrlmode_supported of the current M_CAN driver. Signed-off-by: Oliver Hartkopp Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 96bfa3859e9c40f53ecc79ea3c23dbb72188a56b Author: Oliver Hartkopp Date: Mon Jan 5 18:40:15 2015 +0100 can: dev: fix crtlmode_supported check commit 9b1087aa5e86448fe6ad40a58964e35f3ba423d5 upstream. When changing flags in the CAN drivers ctrlmode the provided new content has to be checked whether the bits are allowed to be changed. The bits that are to be changed are given as a bitfield in cm->mask. Therefore checking against cm->flags is wrong as the content can hold any kind of values. The iproute2 tool sets the bits in cm->mask and cm->flags depending on the detected command line options. To be robust against bogus user space applications additionally sanitize the provided flags with the provided mask. Cc: Wolfgang Grandegger Signed-off-by: Oliver Hartkopp Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman