kernel/linux.git, branch v3.12.37

Linux 3.12.37

2015-01-29T14:45:17+00:00

deal with deadlock in d_walk()

2015-01-29T14:45:17+00:00

commit ca5358ef75fc69fee5322a38a340f5739d997c10 upstream. ... by not hitting rename_retry for reasons other than rename having happened. In other words, do _not_ restart when finding that between unlocking the child and locking the parent the former got into __dentry_kill(). Skip the killed siblings instead... Signed-off-by: Al Viro Acked-by: Miklos Szeredi Signed-off-by: Jiri Slaby

move d_rcu from overlapping d_child to overlapping d_alias

2015-01-29T14:45:16+00:00

commit 946e51f2bf37f1656916eb75bd0742ba33983c28 upstream. Signed-off-by: Al Viro Acked-by: Miklos Szeredi Signed-off-by: Jiri Slaby

usb: musb: Fix a few off-by-one lengths

2015-01-29T14:45:15+00:00

commit e87c3f80ad0490d26ffe04754b7d094463b40f30 upstream. !strncmp(buf, "force host", 9) is true if and only if buf starts with "force hos". This was obviously not what was intended. The same error exists for "force full-speed", "force high-speed" and "test packet". Using strstarts avoids the error-prone hardcoding of the prefix length. For consistency, also change the other occurences of the !strncmp idiom. Signed-off-by: Rasmus Villemoes Signed-off-by: Felipe Balbi Signed-off-by: Jiri Slaby

USB: adutux: NULL dereferences on disconnect

2015-01-29T14:45:15+00:00

commit fc625960edecfb57e62c2975d1f155155e28e6ba upstream. Both "dev->udev" and "interface->dev" are NULL. These printks are not very interesting so I just deleted them. Fixes: 03270634e242 ('USB: Add ADU support for Ontrak ADU devices') Signed-off-by: Dan Carpenter Signed-off-by: Greg Kroah-Hartman Signed-off-by: Jiri Slaby

md/raid5: fetch_block must fetch all the blocks handle_stripe_dirtying wants.

2015-01-29T14:45:14+00:00

commit 108cef3aa41669610e1836fe638812dd067d72de upstream. It is critical that fetch_block() and handle_stripe_dirtying() are consistent in their analysis of what needs to be loaded. Otherwise raid5 can wait forever for a block that won't be loaded. Currently when writing to a RAID5 that is resyncing, to a location beyond the resync offset, handle_stripe_dirtying chooses a reconstruct-write cycle, but fetch_block() assumes a read-modify-write, and a lockup can happen. So treat that case just like RAID6, just as we do in handle_stripe_dirtying. RAID6 always does reconstruct-write. This bug was introduced when the behaviour of handle_stripe_dirtying was changed in 3.7, so the patch is suitable for any kernel since, though it will need careful merging for some versions. Cc: stable@vger.kernel.org (v3.7+) Fixes: a7854487cd7128a30a7f4f5259de9f67d5efb95f Reported-by: Henry Cai Signed-off-by: NeilBrown Signed-off-by: Jiri Slaby

mm: get rid of radix tree gfp mask for pagecache_get_page

2015-01-29T14:45:13+00:00

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: Jiri Slaby

mmc: sdhci: Don't signal the sdio irq if it's not setup

2015-01-29T14:45:13+00:00

[Not needed in newer kernels due to refactoring fixing this issue.] With 3.14.29 (and older kernels) some of my I.mx6 Sabrelite boards were crashing with the following oops: sdhci: Secure Digital Host Controller Interface driver sdhci: Copyright(c) Pierre Ossman sdhci-pltfm: SDHCI platform and OF driver helper sdhci-esdhc-imx 2198000.usdhc: could not get ultra high speed state, work on normal mode mmc0: no vqmmc regulator found mmc0: SDHCI controller on 2198000.usdhc [2198000.usdhc] using ADMA Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = c0004000 [00000000] *pgd=00000000 Internal error: Oops: 5 [#1] SMP ARM Modules linked in: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.14.29 #1 task: c08a7120 ti: c089c000 task.ti: c089c000 PC is at wake_up_process+0x8/0x40 LR is at sdhci_irq+0x748/0x9c4 Full boot log can be found at: http://storage.kernelci.org/stable/v3.14.29/arm-multi_v7_defconfig/lab-collabora/boot-imx6q-sabrelite.html This happens if the sdhci interrupt status contains SDHCI_INT_CARD_INT, while the sdio irq was never setup. This patch fixes that in a minimal way by checking if the sdio irq was setup. In more recent kernels this bug went away due to refactoring done by Russel King. So an alternative (potentially better?) fix for this patch is to cherrypick the following patches from a recent kernel: 18258f7239a6 - genirq: Provide synchronize_hardirq() bf3b5ec66bd0 - mmc: sdio_irq: rework sdio irq handling 41005003bcaf - mmc: sdhci: clean up interrupt handling 781e989cf593 - mmc: sdhci: convert to new SDIO IRQ handling Signed-off-by: Sjoerd Simons Cc: Russell King Cc: Tyler Baker Signed-off-by: Jiri Slaby

crypto: add missing crypto module aliases

2015-01-29T14:45:12+00:00

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: Jiri Slaby

crypto: include crypto- module prefix in template

2015-01-29T14:45:11+00:00

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: Jiri Slaby