aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2014-10-15arm: kvm: STRICT_MM_TYPECHECKS fix for user_mem_abortSteve Capper1-1/+1
Commit: b886576 ARM: KVM: user_mem_abort: support stage 2 MMIO page mapping introduced some code in user_mem_abort that failed to compile if STRICT_MM_TYPECHECKS was enabled. This patch fixes up the failing comparison. Signed-off-by: Steve Capper <[email protected]> Reviewed-by: Kim Phillips <[email protected]> Signed-off-by: Christoffer Dall <[email protected]>
2014-10-15dmaengine: pl330: Fix NULL pointer dereference on driver unbindKrzysztof Kozlowski1-2/+4
Fix a NULL pointer dereference after unbinding the driver, if channel resources were not yet allocated (no call to pl330_alloc_chan_resources()): $ echo 12850000.mdma > /sys/bus/amba/drivers/dma-pl330/unbind [ 13.606533] DMA pl330_control: removing pch: eeab6800, chan: eeab6814, thread: (null) [ 13.614472] Unable to handle kernel NULL pointer dereference at virtual address 0000000c [ 13.622537] pgd = ee284000 [ 13.625228] [0000000c] *pgd=6e1e4831, *pte=00000000, *ppte=00000000 [ 13.631482] Internal error: Oops: 17 [#1] PREEMPT SMP ARM [ 13.636859] Modules linked in: [ 13.639903] CPU: 0 PID: 1 Comm: sh Not tainted 3.17.0-rc3-next-20140904-00004-g7020ffc33ca3-dirty #420 [ 13.649187] task: ee80a800 ti: ee888000 task.ti: ee888000 [ 13.654589] PC is at _stop+0x8/0x2c8 [ 13.658131] LR is at pl330_control+0x70/0x2e8 [ 13.662468] pc : [<c0206028>] lr : [<c020649c>] psr: 60000093 [ 13.662468] sp : ee889e58 ip : 00000001 fp : 000bab70 [ 13.673922] r10: eeab6814 r9 : ee16debc r8 : 00000000 [ 13.679131] r7 : eeab685c r6 : 60000013 r5 : ee16de10 r4 : eeab6800 [ 13.685641] r3 : 00000002 r2 : 00000000 r1 : 00010000 r0 : 00000000 [ 13.692153] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user [ 13.699357] Control: 10c5387d Table: 6e28404a DAC: 00000015 [ 13.705085] Process sh (pid: 1, stack limit = 0xee888240) [ 13.710466] Stack: (0xee889e58 to 0xee88a000) [ 13.714808] 9e40: 00000002 eeab6800 [ 13.722969] 9e60: ee16de10 eeab6800 ee16de10 60000013 eeab685c c020649c 00000000 c040280c [ 13.731128] 9e80: ee889e80 ee889e80 ee16de18 ee16de10 eeab6880 eeab6814 00200200 eeab68a8 [ 13.739287] 9ea0: 00100100 c0208048 00000000 c0409fc4 eea80800 eea808f8 c0605c44 0000000e [ 13.747446] 9ec0: 0000000e eeb3960c eeb39600 c0203c48 eea80800 c0605c44 c0605a8c c023f694 [ 13.755605] 9ee0: ee80a800 eea80834 eea80800 c023f704 ee80a800 eea80800 c0605c44 c023e8ec [ 13.763764] 9f00: 0000000e ee149780 ee29e580 ee889f80 ee29e580 c023e19c 0000000e c01167e4 [ 13.771923] 9f20: c01167a0 00000000 00000000 c0115e88 00000000 00000000 ee0b1a00 0000000e [ 13.780082] 9f40: b6f48000 ee889f80 0000000e ee888000 b6f48000 c00bfadc 00000000 00000003 [ 13.788241] 9f60: 00000000 00000000 00000000 ee0b1a00 ee0b1a00 0000000e b6f48000 c00bfdf4 [ 13.796401] 9f80: 00000000 00000000 ffffffff 0000000e b6f48000 b6edc5d0 00000004 c000e7a4 [ 13.804560] 9fa0: 00000000 c000e620 0000000e b6f48000 00000001 b6f48000 0000000e 00000000 [ 13.812719] 9fc0: 0000000e b6f48000 b6edc5d0 00000004 0000000e b6f4c8c0 000c3470 000bab70 [ 13.820879] 9fe0: 00000000 bed2aa50 b6e18bdc b6e6b52c 60000010 00000001 c0c0c0c0 c0c0c0c0 [ 13.829058] [<c0206028>] (_stop) from [<c020649c>] (pl330_control+0x70/0x2e8) [ 13.836165] [<c020649c>] (pl330_control) from [<c0208048>] (pl330_remove+0xb0/0xdc) [ 13.843800] [<c0208048>] (pl330_remove) from [<c0203c48>] (amba_remove+0x24/0xc0) [ 13.851272] [<c0203c48>] (amba_remove) from [<c023f694>] (__device_release_driver+0x70/0xc4) [ 13.859685] [<c023f694>] (__device_release_driver) from [<c023f704>] (device_release_driver+0x1c/0x28) [ 13.868971] [<c023f704>] (device_release_driver) from [<c023e8ec>] (unbind_store+0x58/0x90) [ 13.877303] [<c023e8ec>] (unbind_store) from [<c023e19c>] (drv_attr_store+0x20/0x2c) [ 13.885036] [<c023e19c>] (drv_attr_store) from [<c01167e4>] (sysfs_kf_write+0x44/0x48) [ 13.892928] [<c01167e4>] (sysfs_kf_write) from [<c0115e88>] (kernfs_fop_write+0xc0/0x17c) [ 13.901090] [<c0115e88>] (kernfs_fop_write) from [<c00bfadc>] (vfs_write+0xa0/0x1a8) [ 13.908812] [<c00bfadc>] (vfs_write) from [<c00bfdf4>] (SyS_write+0x40/0x8c) [ 13.915850] [<c00bfdf4>] (SyS_write) from [<c000e620>] (ret_fast_syscall+0x0/0x30) [ 13.923392] Code: e5813010 e12fff1e e92d40f0 e24dd00c (e590200c) [ 13.929467] ---[ end trace 10064e15a5929cf8 ]--- Terminate the thread and free channel resource only if channel resources were allocated (thread is not NULL). Signed-off-by: Krzysztof Kozlowski <[email protected]> Cc: <[email protected]> Fixes: b3040e40675e ("DMA: PL330: Add dma api driver") Reviewed-by: Lars-Peter Clausen <[email protected]> Signed-off-by: Vinod Koul <[email protected]>
2014-10-15dmaengine: pl330: Fix NULL pointer dereference on probe failureKrzysztof Kozlowski1-2/+4
If dma_async_device_register() returns error and probe should clean up and return error, a NULL pointer exception happens because of dereference of not allocated channel thread: Dmesg log (from early printk): dma-pl330 12680000.pdma: unable to register DMAC DMA pl330_control: removing pch: eeac4000, chan: eeac4014, thread: (null) Unable to handle kernel NULL pointer dereference at virtual address 0000000c pgd = c0004000 [0000000c] *pgd=00000000 Internal error: Oops: 5 [#1] PREEMPT SMP ARM Modules linked in: CPU: 2 PID: 1 Comm: swapper/0 Not tainted 3.17.0-rc3-next-20140904-00005-g6cc4c1937d90-dirty #427 task: ee80a800 ti: ee888000 task.ti: ee888000 PC is at _stop+0x8/0x2c8 LR is at pl330_control+0x70/0x2e8 pc : [<c0205dc8>] lr : [<c020623c>] psr: 60000193 sp : ee889df8 ip : 00000002 fp : 00000000 r10: eeac4014 r9 : ee0e62bc r8 : 00000000 r7 : eeac405c r6 : 60000113 r5 : ee0e6210 r4 : eeac4000 r3 : 00000002 r2 : 00000002 r1 : 00010000 r0 : 00000000 Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c5387d Table: 4000404a DAC: 00000015 Process swapper/0 (pid: 1, stack limit = 0xee888240) Stack: (0xee889df8 to 0xee88a000) 9de0: 00000002 eeac4000 9e00: ee0e6210 eeac4000 ee0e6210 60000113 eeac405c c020623c 00000000 c020725c 9e20: ee889e20 ee889e20 ee0e6210 eeac4080 00200200 00100100 eeac4014 00000020 9e40: ee0e6218 c0208374 00000000 ee9bb340 ee0e6210 00000000 00000000 c0605cd8 9e60: ee970000 c0605c84 ee9700f8 00000000 c05c4270 00000000 00000000 c0203b3c 9e80: ee970000 c06624a8 00000000 c0605c84 00000000 c023f890 ee970000 c0605c84 9ea0: ee970034 00000000 c05b23d0 c023fa3c 00000000 c0605c84 c023f9b0 c023e0d4 9ec0: ee947e78 ee9b9440 c0605c84 eea1e780 c0605acc c023f094 c0513b50 c0605c84 9ee0: c05ecbd8 c0605c84 c05ecbd8 ee11ba40 c0626500 c0240064 00000000 c05ecbd8 9f00: c05ecbd8 c0008964 c040f13c 0000009f c0626500 c057465c ee80a800 60000113 9f20: 00000000 c05efdb0 60000113 00000000 ef7fc89d c0421168 0000008f c003787c 9f40: c0573d6c 00000006 ef7fc8bb 00000006 c05efd50 ef7fc800 c05dfbc4 00000006 9f60: c05c4264 c0626500 0000008f c05c4270 c059b518 c059bcb4 00000006 00000006 9f80: c059b518 c003c08c 00000000 c040091c 00000000 00000000 00000000 00000000 9fa0: 00000000 c0400924 00000000 c000e7b8 00000000 00000000 00000000 00000000 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 c0c0c0c0 c0c0c0c0 [<c0205dc8>] (_stop) from [<c020623c>] (pl330_control+0x70/0x2e8) [<c020623c>] (pl330_control) from [<c0208374>] (pl330_probe+0x594/0x75c) [<c0208374>] (pl330_probe) from [<c0203b3c>] (amba_probe+0xb8/0x120) [<c0203b3c>] (amba_probe) from [<c023f890>] (driver_probe_device+0x10c/0x22c) [<c023f890>] (driver_probe_device) from [<c023fa3c>] (__driver_attach+0x8c/0x90) [<c023fa3c>] (__driver_attach) from [<c023e0d4>] (bus_for_each_dev+0x54/0x88) [<c023e0d4>] (bus_for_each_dev) from [<c023f094>] (bus_add_driver+0xd4/0x1d0) [<c023f094>] (bus_add_driver) from [<c0240064>] (driver_register+0x78/0xf4) [<c0240064>] (driver_register) from [<c0008964>] (do_one_initcall+0x80/0x1d0) [<c0008964>] (do_one_initcall) from [<c059bcb4>] (kernel_init_freeable+0x108/0x1d4) [<c059bcb4>] (kernel_init_freeable) from [<c0400924>] (kernel_init+0x8/0xec) [<c0400924>] (kernel_init) from [<c000e7b8>] (ret_from_fork+0x14/0x3c) Code: e5813010 e12fff1e e92d40f0 e24dd00c (e590200c) ---[ end trace c94b2f4f38dff3bf ]--- This happens because the necessary resources were not yet allocated - no call to pl330_alloc_chan_resources(). Terminate the thread and free channel resource only if channel thread is not NULL. Signed-off-by: Krzysztof Kozlowski <[email protected]> Cc: <[email protected]> Fixes: 0b94c5771705 ("DMA: PL330: Add check if device tree compatible") Reviewed-by: Lars-Peter Clausen <[email protected]> Signed-off-by: Vinod Koul <[email protected]>
2014-10-15dmaengine: pl330: Remove unused 'regs' variable in pl330_submit_req()Krzysztof Kozlowski1-3/+0
The 'void __iomem *regs' is not used in pl330_submit_req() function. Remove it. Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Vinod Koul <[email protected]>
2014-10-15dmaengine: pl330: Remove non-NULL check for pl330_submit_req parametersKrzysztof Kozlowski1-4/+0
The pl330_submit_req() checked supplied 'struct pl330_thread thrd' and 'struct dma_pl330_desc desc' parameters for non-NULL. However these checks are useless because supplied arguments won't be NULL. The pl330_submit_req() is called in only one place and: 1. 'desc' is already dereferenced in fill_queue() before calling pl330_submit_req(). 2. 'thrd' is always dereferenced after calling fill_queue()->pl330_submit_req(). Removing the checks for non-NULL values fixes following warning: drivers/dma/pl330.c:1376 pl330_submit_req() warn: variable dereferenced before check 'thrd' (see line 1367) Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Vinod Koul <[email protected]>
2014-10-14MAINTAINERS: Update Santosh Shilimkar's email idSantosh Shilimkar1-7/+7
Signed-off-by: Santosh Shilimkar <[email protected]> Signed-off-by: Olof Johansson <[email protected]>
2014-10-14Merge tag 'samsung-defconfig' of ↵Olof Johansson1-0/+10
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung into fixes Merge "Samsung defconfig, actually exynos_defconig updates for v3.18" from Kukjin Kim: - enable USB gadget support - enable Maxim77802 support - enable Maxim77693 and I2C GPIO drivers - enable Atmel maXTouch support - enable SBS battery support - enable Control Groups support * tag 'samsung-defconfig' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung: ARM: exynos_defconfig: enable USB gadget support ARM: exynos_defconfig: Enable Maxim 77693 and I2C GPIO drivers ARM: exynos_defconfig: Enable SBS battery support ARM: exynos_defconfig: Enable Control Groups support ARM: exynos_defconfig: Enable Atmel maXTouch support ARM: exynos_defconfig: Enable MAX77802 Signed-off-by: Olof Johansson <[email protected]>
2014-10-14Merge tag 'samsung-fixes' of ↵Olof Johansson5-4/+8
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung into fixes Merge "Samsung fixes for v3.18" from Kukjin Kim: - fix ifdef around cpu_*_do_[suspend, resume] ops to check CONFIG_ARM_CPU_SUSPEND and not CONFIG_PM_SLEEP - fix exynos_defconfig build with PM_SLEEP=n and ARM_EXYNOS_CPUIDLE=n - fix enabling Samsung PM debug functionality due to recently merged patches and previous merge conflicts - fix pull-up setting in sd4_width8 pin group for exynos4x12 * tag 'samsung-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung: ARM: mm: Fix ifdef around cpu_*_do_[suspend, resume] ops ARM: EXYNOS: Fix build with PM_SLEEP=n and ARM_EXYNOS_CPUIDLE=n ARM: SAMSUNG: Restore Samsung PM Debug functionality ARM: dts: Fix pull setting in sd4_width8 pin group for exynos4x12 Signed-off-by: Olof Johansson <[email protected]>
2014-10-14Merge tag 'fixes-for-v3.18-merge-window' of ↵Olof Johansson2-0/+4
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes Merge "Two omap fixes for v3.18 merge window" from Tony Lindgren: Two omap fixes for issues noticed during the merge window: - We need to enable ARM errata 430973 for omap3 - The smc91x on some early n900 boards need to be disabled for now until the dependencies to specific a bootloader version are fixed * tag 'fixes-for-v3.18-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: ARM: dts: Disable smc91x on n900 until bootloader dependency is removed ARM: omap2plus_defconfig: Enable ARM erratum 430973 for omap3 Signed-off-by: Olof Johansson <[email protected]>
2014-10-14ARM: sunxi_defconfig: enable CONFIG_REGULATOROlof Johansson1-0/+1
Commit 97a13e5289ba ('net: phy: mdio-sun4i: don't select REGULATOR') removed the select of REGULATOR, which means that it now has to be explicitly enabled in the defconfig or things won't work very well. In particular, this fixes a problem with SD/MMC not probing on my A31-based board. Cc: Beniamino Galvani <[email protected]> Signed-off-by: Olof Johansson <[email protected]>
2014-10-15Merge branch 'for-3.18-consistent-ops' of ↵Linus Torvalds149-547/+560
git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu Pull percpu consistent-ops changes from Tejun Heo: "Way back, before the current percpu allocator was implemented, static and dynamic percpu memory areas were allocated and handled separately and had their own accessors. The distinction has been gone for many years now; however, the now duplicate two sets of accessors remained with the pointer based ones - this_cpu_*() - evolving various other operations over time. During the process, we also accumulated other inconsistent operations. This pull request contains Christoph's patches to clean up the duplicate accessor situation. __get_cpu_var() uses are replaced with with this_cpu_ptr() and __this_cpu_ptr() with raw_cpu_ptr(). Unfortunately, the former sometimes is tricky thanks to C being a bit messy with the distinction between lvalues and pointers, which led to a rather ugly solution for cpumask_var_t involving the introduction of this_cpu_cpumask_var_ptr(). This converts most of the uses but not all. Christoph will follow up with the remaining conversions in this merge window and hopefully remove the obsolete accessors" * 'for-3.18-consistent-ops' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu: (38 commits) irqchip: Properly fetch the per cpu offset percpu: Resolve ambiguities in __get_cpu_var/cpumask_var_t -fix ia64: sn_nodepda cannot be assigned to after this_cpu conversion. Use __this_cpu_write. percpu: Resolve ambiguities in __get_cpu_var/cpumask_var_t Revert "powerpc: Replace __get_cpu_var uses" percpu: Remove __this_cpu_ptr clocksource: Replace __this_cpu_ptr with raw_cpu_ptr sparc: Replace __get_cpu_var uses avr32: Replace __get_cpu_var with __this_cpu_write blackfin: Replace __get_cpu_var uses tile: Use this_cpu_ptr() for hardware counters tile: Replace __get_cpu_var uses powerpc: Replace __get_cpu_var uses alpha: Replace __get_cpu_var ia64: Replace __get_cpu_var uses s390: cio driver &__get_cpu_var replacements s390: Replace __get_cpu_var uses mips: Replace __get_cpu_var uses MIPS: Replace __get_cpu_var uses in FPU emulator. arm: Replace __this_cpu_ptr with raw_cpu_ptr ...
2014-10-15Merge tag 'llvmlinux-for-v3.18' of ↵Linus Torvalds12-159/+122
git://git.linuxfoundation.org/llvmlinux/kernel Pull LLVM updates from Behan Webster: "These patches remove the use of VLAIS using a new SHASH_DESC_ON_STACK macro. Some of the previously accepted VLAIS removal patches haven't used this macro. I will push new patches to consistently use this macro in all those older cases for 3.19" [ More LLVM patches coming in through subsystem trees, and LLVM itself needs some fixes that are already in many distributions but not in released versions of LLVM. Some day this will all "just work" - Linus ] * tag 'llvmlinux-for-v3.18' of git://git.linuxfoundation.org/llvmlinux/kernel: crypto: LLVMLinux: Remove VLAIS usage from crypto/testmgr.c security, crypto: LLVMLinux: Remove VLAIS from ima_crypto.c crypto: LLVMLinux: Remove VLAIS usage from libcrc32c.c crypto: LLVMLinux: Remove VLAIS usage from crypto/hmac.c crypto, dm: LLVMLinux: Remove VLAIS usage from dm-crypt crypto: LLVMLinux: Remove VLAIS from crypto/.../qat_algs.c crypto: LLVMLinux: Remove VLAIS from crypto/omap_sham.c crypto: LLVMLinux: Remove VLAIS from crypto/n2_core.c crypto: LLVMLinux: Remove VLAIS from crypto/mv_cesa.c crypto: LLVMLinux: Remove VLAIS from crypto/ccp/ccp-crypto-sha.c btrfs: LLVMLinux: Remove VLAIS crypto: LLVMLinux: Add macro to remove use of VLAIS in crypto code
2014-10-15Merge tag 'iommu-updates-v3.18' of ↵Linus Torvalds25-356/+461
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu Pull IOMMU updates from Joerg Roedel: "This pull-request includes: - change in the IOMMU-API to convert the former iommu_domain_capable function to just iommu_capable - various fixes in handling RMRR ranges for the VT-d driver (one fix requires a device driver core change which was acked by Greg KH) - the AMD IOMMU driver now assigns and deassigns complete alias groups to fix issues with devices using the wrong PCI request-id - MMU-401 support for the ARM SMMU driver - multi-master IOMMU group support for the ARM SMMU driver - various other small fixes all over the place" * tag 'iommu-updates-v3.18' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu: (41 commits) iommu/vt-d: Work around broken RMRR firmware entries iommu/vt-d: Store bus information in RMRR PCI device path iommu/vt-d: Only remove domain when device is removed driver core: Add BUS_NOTIFY_REMOVED_DEVICE event iommu/amd: Fix devid mapping for ivrs_ioapic override iommu/irq_remapping: Fix the regression of hpet irq remapping iommu: Fix bus notifier breakage iommu/amd: Split init_iommu_group() from iommu_init_device() iommu: Rework iommu_group_get_for_pci_dev() iommu: Make of_device_id array const amd_iommu: do not dereference a NULL pointer address. iommu/omap: Remove omap_iommu unused owner field iommu: Remove iommu_domain_has_cap() API function IB/usnic: Convert to use new iommu_capable() API function vfio: Convert to use new iommu_capable() API function kvm: iommu: Convert to use new iommu_capable() API function iommu/tegra: Convert to iommu_capable() API function iommu/msm: Convert to iommu_capable() API function iommu/vt-d: Convert to iommu_capable() API function iommu/fsl: Convert to iommu_capable() API function ...
2014-10-15Merge tag 'clk-for-linus-3.18' of ↵Linus Torvalds101-798/+4134
git://git.linaro.org/people/mike.turquette/linux Pull clock tree updates from Mike Turquette: "The clk tree changes for 3.18 are dominated by clock drivers. Mostly fixes and enhancements to existing drivers as well as new drivers. This tag contains a bit more arch code than I usually take due to some OMAP2+ changes. Additionally it contains the restart notifier handlers which are merged as a dependency into several trees. The PXA changes are the only messy part. Due to having a stable tree I had to revert one patch and follow up with one more fix near the tip of this tag. Some dead code is introduced but it will soon become live code after 3.18-rc1 is released as the rest of the PXA family is converted over to the common clock framework. Another trend in this tag is that multiple vendors have started to push the complexity of changing their CPU frequency into the clock driver, whereas this used to be done in CPUfreq drivers. Changes to the clk core include a generic gpio-clock type and a clk_set_phase() function added to the top-level clk.h api. Due to some confusion on the fbdev mailing list the kernel boot parameters documentation was updated to further explain the clk_ignore_unused parameter, which is often required by users of the simplefb driver. Finally some fixes to the locking around the clock debugfs stuff was done to prevent deadlocks when interacting with other subsystems." * tag 'clk-for-linus-3.18' of git://git.linaro.org/people/mike.turquette/linux: (99 commits) clk: pxa clocks build system fix Revert "arm: pxa: Transition pxa27x to clk framework" clk: samsung: register restart handlers for s3c2412 and s3c2443 clk: rockchip: add restart handler clk: rockchip: rk3288: i2s_frac adds flag to set parent's rate doc/kernel-parameters.txt: clarify clk_ignore_unused arm: pxa: Transition pxa27x to clk framework dts: add devicetree bindings for pxa27x clocks clk: add pxa27x clock drivers arm: pxa: add clock pll selection bits clk: dts: document pxa clock binding clk: add pxa clocks infrastructure clk: gpio-gate: Ensure gpiod_ APIs are prototyped clk: ti: dra7-atl-clock: Mark the device as pm_runtime_irq_safe clk: ti: LLVMLinux: Move __init outside of type definition clk: ti: consider the fact that of_clk_get() might return an error clk: ti: dra7-atl-clock: fix a memory leak clk: ti: change clock init to use generic of_clk_init clk: hix5hd2: add I2C clocks clk: hix5hd2: add watchdog0 clocks ...
2014-10-15Merge tag 'mfd-for-linus-3.18' of ↵Linus Torvalds70-403/+2061
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd Pull MFD updates from Lee Jones: "Changes to existing drivers: - DT clean-ups in da9055-core, max14577, rn5t618, arizona, hi6421, stmpe, twl4030 - Export symbols for use in modules in max14577 - Plenty of static code analysis/Coccinelle fixes throughout the SS - Regmap clean-ups in arizona, wm5102, wm5110, da9052, tps65217, rk808 - Remove unused/duplicate code in da9052, 88pm860x, ti_ssp, lpc_sch, arizona - Bug fixes in ti_am335x_tscadc, da9052, ti_am335x_tscadc, rtsx_pcr - IRQ fixups in arizona, stmpe, max14577 - Regulator related changes in axp20x - Pass DMA coherency information from parent => child in MFD core - Rename DT document files for consistency - Add ACPI support to the MFD core - Add Andreas Werner to MAINTAINERS for MEN F21BMC New drivers/supported devices: - New driver for MEN 14F021P00 Board Management Controller - New driver for Ricoh RN5T618 PMIC - New driver for Rockchip RK808 - New driver for HiSilicon Hi6421 PMIC - New driver for Qualcomm SPMI PMICs - Add support for Intel Braswell in lpc_ich - Add support for Intel 9 Series PCH in lpc_ich - Add support for Intel Quark ILB in lpc_sch" [ Delayed to after the poweer/reset pull due to Kconfig problems with recursive Kconfig select/depends-on chains. - Linus ] * tag 'mfd-for-linus-3.18' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd: (79 commits) mfd: cros_ec: wait for completion of commands that return IN_PROGRESS i2c: i2c-cros-ec-tunnel: Set retries to 3 mfd: cros_ec: move locking into cros_ec_cmd_xfer mfd: cros_ec: stop calling ->cmd_xfer() directly mfd: cros_ec: Delay for 50ms when we see EC_CMD_REBOOT_EC MAINTAINERS: Adds Andreas Werner to maintainers list for MEN F21BMC mfd: arizona: Correct mask to allow setting micbias external cap mfd: Add ACPI support Revert "mfd: wm5102: Manually apply register patch" mfd: ti_am335x_tscadc: Update logic in CTRL register for 5-wire TS mfd: dt-bindings: atmel-gpbr: Rename doc file to conform to naming convention mfd: dt-bindings: qcom-pm8xxx: Rename doc file to conform to naming convention mfd: Inherit coherent_dma_mask from parent device mfd: Document DT bindings for Qualcomm SPMI PMICs mfd: Add support for Qualcomm SPMI PMICs mfd: dt-bindings: pm8xxx: Add new compatible string mfd: axp209x: Drop the parent supplies field mfd: twl4030-power: Use 'ti,system-power-controller' as alternative way to support system power off mfd: dt-bindings: twl4030-power: Use the standard property to mark power control mfd: syscon: Add Atmel GPBR DT bindings documention ...
2014-10-15Merge tag 'for-v3.18' of git://git.infradead.org/battery-2.6Linus Torvalds33-249/+1919
Pull power supply and reset updates from Sebastian Reichel: - Initial support for the following chips * max77836 (charger) * max14577 (charger) * bq27742 (battery gauge) * ltc2952 (poweroff) * stih416 (restart) * syscon-reboot (restart) * gpio-restart (restart) - cleanup of power supply core - misc fixes in power supply and reset drivers * tag 'for-v3.18' of git://git.infradead.org/battery-2.6: (48 commits) power: ab8500_fg: Fix build warning Documentation: charger: max14577: Update the date of introducing ABI power: reset: corrections for simple syscon reboot driver Documentation: power: reset: Add documentation for generic SYSCON reboot driver power: reset: Add generic SYSCON register mapped reset bq27x00_battery: Fix flag reading for bq27742 power: reset: use restart_notifier mechanism for msm-poweroff power: Add simple gpio-restart driver power: reset: st: Provide DT bindings for ST's Power Reset driver power: reset: Add restart functionality for STiH41x platforms power: charger-manager: Fix NULL pointer exception with missing cm-fuel-gauge power: max14577: Fix circular config SYSFS dependency power: gpio-charger: do not use gpio value directly power: max8925: Use of_get_child_by_name power: max8925: Fix NULL ptr dereference on memory allocation failure bq27x00_battery: Add support to bq27742 Documentation: charger: max14577: Document exported sysfs entry devicetree: mfd: max14577: Add device tree bindings document power: max17040: Add ID for MAX77836 Fuel Gauge block charger: max14577: Configure battery-dependent settings from DTS and sysfs ... Conflicts: drivers/power/reset/Kconfig drivers/power/reset/Makefile
2014-10-15Merge branch 'for-linus' of ↵Linus Torvalds25-623/+948
git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client Pull Ceph updates from Sage Weil: "There is the long-awaited discard support for RBD (Guangliang Zhao, Josh Durgin), a pile of RBD bug fixes that didn't belong in late -rc's (Ilya Dryomov, Li RongQing), a pile of fs/ceph bug fixes and performance and debugging improvements (Yan, Zheng, John Spray), and a smattering of cleanups (Chao Yu, Fabian Frederick, Joe Perches)" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client: (40 commits) ceph: fix divide-by-zero in __validate_layout() rbd: rbd workqueues need a resque worker libceph: ceph-msgr workqueue needs a resque worker ceph: fix bool assignments libceph: separate multiple ops with commas in debugfs output libceph: sync osd op definitions in rados.h libceph: remove redundant declaration ceph: additional debugfs output ceph: export ceph_session_state_name function ceph: include the initial ACL in create/mkdir/mknod MDS requests ceph: use pagelist to present MDS request data libceph: reference counting pagelist ceph: fix llistxattr on symlink ceph: send client metadata to MDS ceph: remove redundant code for max file size verification ceph: remove redundant io_iter_advance() ceph: move ceph_find_inode() outside the s_mutex ceph: request xattrs if xattr_version is zero rbd: set the remaining discard properties to enable support rbd: use helpers to handle discard for layered images correctly ...
2014-10-15Merge branch 'CVE-2014-7970' of ↵Linus Torvalds1-0/+3
git://git.kernel.org/pub/scm/linux/kernel/git/luto/linux Pull pivot_root() fix from Andy Lutomirski. Prevent a leak of unreachable mounts. * 'CVE-2014-7970' of git://git.kernel.org/pub/scm/linux/kernel/git/luto/linux: mnt: Prevent pivot_root from creating a loop in the mount tree
2014-10-15Merge branch 'cxgb4'David S. Miller4-139/+26
Anish Bhatt says: ==================== ipv6 and related cleanup for cxgb4/cxgb4i This patch set removes some duplicated/extraneous code from cxgb4i, guards cxgb4 against compilation failure based on ipv6 tristate, make ipv6 related code no longer be enabled by default irrespective of ipv6 tristate and fixes a refcnt issue. -Anish v2 : Provide more detailed commit messages, make subject more concise as recommended by Dave Miller. ==================== Signed-off-by: David S. Miller <[email protected]>
2014-10-15cxgb4i: Remove duplicate call to dst_neigh_lookup()Anish Bhatt1-5/+0
There is an extra call to dst_neigh_lookup() leftover in cxgb4i that can cause an unreleased refcnt issue. Remove extraneous call. Signed-off-by: Anish Bhatt <[email protected]> Fixes : 759a0cc5a3e1b ('cxgb4i: Add ipv6 code to driver, call into libcxgbi ipv6 api') Signed-off-by: David S. Miller <[email protected]>
2014-10-15cxgb4i : Fix -Wunused-function warningAnish Bhatt2-0/+10
A bunch of ipv6 related code is left on by default. While this causes no compilation issues, there is no need to have this enabled by default. Guard with an ipv6 check, which also takes care of a -Wunused-function warning. Signed-off-by: Anish Bhatt <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-10-15cxgb4 : Fix build failure in cxgb4 when ipv6 is disabled/not in-builtAnish Bhatt2-1/+9
cxgb4 ipv6 does not guard against ipv6 being disabled, or the standard ipv6 module vs inbuilt tri-state issue. This was fixed for cxgb4i & iw_cxgb4 but missed for cxgb4. Signed-off-by: Anish Bhatt <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-10-15cxgb4i : Remove duplicated CLIP handling codeAnish Bhatt2-133/+7
cxgb4 already handles CLIP updates from a previous changeset for iw_cxgb4, there is no need to have this functionality in cxgb4i. Remove duplicated code Signed-off-by: Anish Bhatt <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-10-14sparc64: Fix FPU register corruption with AES crypto offload.David S. Miller2-1/+21
The AES loops in arch/sparc/crypto/aes_glue.c use a scheme where the key material is preloaded into the FPU registers, and then we loop over and over doing the crypt operation, reusing those pre-cooked key registers. There are intervening blkcipher*() calls between the crypt operation calls. And those might perform memcpy() and thus also try to use the FPU. The sparc64 kernel FPU usage mechanism is designed to allow such recursive uses, but with a catch. There has to be a trap between the two FPU using threads of control. The mechanism works by, when the FPU is already in use by the kernel, allocating a slot for FPU saving at trap time. Then if, within the trap handler, we try to use the FPU registers, the pre-trap FPU register state is saved into the slot. Then at trap return time we notice this and restore the pre-trap FPU state. Over the long term there are various more involved ways we can make this work, but for a quick fix let's take advantage of the fact that the situation where this happens is very limited. All sparc64 chips that support the crypto instructiosn also are using the Niagara4 memcpy routine, and that routine only uses the FPU for large copies where we can't get the source aligned properly to a multiple of 8 bytes. We look to see if the FPU is already in use in this context, and if so we use the non-large copy path which only uses integer registers. Furthermore, we also limit this special logic to when we are doing kernel copy, rather than a user copy. Signed-off-by: David S. Miller <[email protected]>
2014-10-15virtio-rng: refactor probe error handlingMichael S. Tsirkin1-6/+9
Code like vi->vq = NULL; kfree(vi) does not make sense. Clean it up, use goto error labels for cleanup. Signed-off-by: Michael S. Tsirkin <[email protected]> Signed-off-by: Rusty Russell <[email protected]>
2014-10-15virtio_scsi: drop scan callbackMichael S. Tsirkin1-16/+7
Enable VQs early like we do for restore. This makes it possible to drop the scan callback, moving scanning into the probe function, and making code simpler. Signed-off-by: Michael S. Tsirkin <[email protected]> Signed-off-by: Rusty Russell <[email protected]>
2014-10-15virtio_balloon: enable VQs early on restoreMichael S. Tsirkin1-0/+2
virtio spec requires drivers to set DRIVER_OK before using VQs. This is set automatically after resume returns, virtio balloon violated this rule by adding bufs, which causes the VQ to be used directly within restore. To fix, call virtio_device_ready before using VQ. Signed-off-by: Michael S. Tsirkin <[email protected]> Signed-off-by: Rusty Russell <[email protected]>
2014-10-15virtio_scsi: fix race on device removalMichael S. Tsirkin1-1/+10
We cancel event work on device removal, but an interrupt could trigger immediately after this, and queue it again. To fix, set a flag. Loosely based on patch by Paolo Bonzini Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]> Signed-off-by: Rusty Russell <[email protected]>
2014-10-15virito_scsi: use freezable WQ for eventsPaolo Bonzini1-1/+1
Michael S. Tsirkin noticed a race condition: we reset device on freeze, but system WQ is still running so it might try adding bufs to a VQ meanwhile. To fix, switch to handling events from the freezable WQ. Reported-by: Michael S. Tsirkin <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]> Signed-off-by: Rusty Russell <[email protected]>
2014-10-15virtio_net: enable VQs early on restoreMichael S. Tsirkin1-0/+2
virtio spec requires drivers to set DRIVER_OK before using VQs. This is set automatically after restore returns, virtio net violated this rule by using receive VQs within restore. To fix, call virtio_device_ready before using VQs. Signed-off-by: Michael S. Tsirkin <[email protected]> Reviewed-by: Cornelia Huck <[email protected]> Signed-off-by: Rusty Russell <[email protected]>
2014-10-15virtio_console: enable VQs early on restoreMichael S. Tsirkin1-0/+2
virtio spec requires drivers to set DRIVER_OK before using VQs. This is set automatically after resume returns, virtio console violated this rule by adding inbufs, which causes the VQ to be used directly within restore. To fix, call virtio_device_ready before using VQs. Signed-off-by: Michael S. Tsirkin <[email protected]> Signed-off-by: Rusty Russell <[email protected]>
2014-10-15virtio_scsi: enable VQs early on restoreMichael S. Tsirkin1-0/+2
virtio spec requires drivers to set DRIVER_OK before using VQs. This is set automatically after restore returns, virtio scsi violated this rule on restore by kicking event vq within restore. To fix, call virtio_device_ready before using event queue. Signed-off-by: Michael S. Tsirkin <[email protected]> Signed-off-by: Rusty Russell <[email protected]>
2014-10-15virtio_blk: enable VQs early on restoreMichael S. Tsirkin1-3/+6
virtio spec requires drivers to set DRIVER_OK before using VQs. This is set automatically after restore returns, virtio block violated this rule on restore by restarting queues, which might in theory cause the VQ to be used directly within restore. To fix, call virtio_device_ready before using starting queues. Signed-off-by: Michael S. Tsirkin <[email protected]> Signed-off-by: Rusty Russell <[email protected]>
2014-10-15virtio_scsi: move kick event out from virtscsi_initMichael S. Tsirkin1-5/+11
We currently kick event within virtscsi_init, before host is fully initialized. This can in theory confuse guest if device consumes the buffers immediately. To fix, move virtscsi_kick_event_all out to scan/restore. Signed-off-by: Michael S. Tsirkin <[email protected]> Signed-off-by: Rusty Russell <[email protected]>
2014-10-15virtio_net: fix use after free on allocation failureMichael S. Tsirkin1-0/+2
In the extremely unlikely event that driver initialization fails after RX buffers are added, virtio net frees RX buffers while VQs are still active, potentially causing device to use a freed buffer. To fix, reset device first - same as we do on device removal. Signed-off-by: Michael S. Tsirkin <[email protected]> Reviewed-by: Cornelia Huck <[email protected]> Signed-off-by: Rusty Russell <[email protected]>
2014-10-159p/trans_virtio: enable VQs earlyMichael S. Tsirkin1-0/+2
virtio spec requires drivers to set DRIVER_OK before using VQs. This is set automatically after probe returns, but virtio 9p device adds self to channel list within probe, at which point VQ can be used in violation of the spec. To fix, call virtio_device_ready before using VQs. Signed-off-by: Michael S. Tsirkin <[email protected]> Signed-off-by: Rusty Russell <[email protected]>
2014-10-15virtio_console: enable VQs earlyMichael S. Tsirkin1-0/+2
virtio spec requires drivers to set DRIVER_OK before using VQs. This is set automatically after probe returns, virtio console violated this rule by adding inbufs, which causes the VQ to be used directly within probe. To fix, call virtio_device_ready before using VQs. Signed-off-by: Michael S. Tsirkin <[email protected]> Signed-off-by: Rusty Russell <[email protected]>
2014-10-15virtio_blk: enable VQs earlyMichael S. Tsirkin1-0/+2
virtio spec requires drivers to set DRIVER_OK before using VQs. This is set automatically after probe returns, virtio block violated this rule by calling add_disk, which causes the VQ to be used directly within probe. To fix, call virtio_device_ready before using VQs. Signed-off-by: Michael S. Tsirkin <[email protected]> Reviewed-by: Cornelia Huck <[email protected]> Signed-off-by: Rusty Russell <[email protected]>
2014-10-15virtio_net: enable VQs earlyMichael S. Tsirkin1-0/+2
virtio spec requires drivers to set DRIVER_OK before using VQs. This is set automatically after probe returns, virtio net violated this rule by using receive VQs within probe. To fix, call virtio_device_ready before using VQs. Signed-off-by: Michael S. Tsirkin <[email protected]> Reviewed-by: Cornelia Huck <[email protected]> Signed-off-by: Rusty Russell <[email protected]>
2014-10-15virtio: add API to enable VQs earlyMichael S. Tsirkin1-0/+17
virtio spec 0.9.X requires DRIVER_OK to be set before VQs are used, but some drivers use VQs before probe function returns. Since DRIVER_OK is set after probe, this violates the spec. Even though under virtio 1.0 transitional devices support this behaviour, we want to make it possible for those early callers to become spec compliant and eventually support non-transitional devices. Add API for drivers to call before using VQs. Sets DRIVER_OK internally. Signed-off-by: Michael S. Tsirkin <[email protected]> Reviewed-by: Cornelia Huck <[email protected]> Signed-off-by: Rusty Russell <[email protected]>
2014-10-15virtio_net: minor cleanupMichael S. Tsirkin1-4/+2
goto done; done: return; is ugly, it was put there to make diff review easier. replace by open-coded return. Signed-off-by: Michael S. Tsirkin <[email protected]> Acked-by: Cornelia Huck <[email protected]> Signed-off-by: Rusty Russell <[email protected]>
2014-10-15virtio-net: drop config_mutexMichael S. Tsirkin1-6/+1
config_mutex served two purposes: prevent multiple concurrent config change handlers, and synchronize access to config_enable flag. Since commit dbf2576e37da0fcc7aacbfbb9fd5d3de7888a3c1 workqueue: make all workqueues non-reentrant all workqueues are non-reentrant, and config_enable is now gone. Get rid of the unnecessary lock. Signed-off-by: Michael S. Tsirkin <[email protected]> Reviewed-by: Cornelia Huck <[email protected]> Signed-off-by: Rusty Russell <[email protected]>
2014-10-15virtio_net: drop config_enableMichael S. Tsirkin1-23/+4
Now that virtio core ensures config changes don't arrive during probing, drop config_enable flag in virtio net. On removal, flush is now sufficient to guarantee that no change work is queued. This help simplify the driver, and will allow setting DRIVER_OK earlier without losing config change notifications. Signed-off-by: Michael S. Tsirkin <[email protected]> Reviewed-by: Cornelia Huck <[email protected]> Signed-off-by: Rusty Russell <[email protected]>
2014-10-15virtio-blk: drop config_mutexMichael S. Tsirkin1-8/+0
config_mutex served two purposes: prevent multiple concurrent config change handlers, and synchronize access to config_enable flag. Since commit dbf2576e37da0fcc7aacbfbb9fd5d3de7888a3c1 workqueue: make all workqueues non-reentrant all workqueues are non-reentrant, and config_enable is now gone. Get rid of the unnecessary lock. Signed-off-by: Michael S. Tsirkin <[email protected]> Reviewed-by: Cornelia Huck <[email protected]> Signed-off-by: Rusty Russell <[email protected]>
2014-10-15virtio_blk: drop config_enableMichael S. Tsirkin1-19/+4
Now that virtio core ensures config changes don't arrive during probing, drop config_enable flag in virtio blk. On removal, flush is now sufficient to guarantee that no change work is queued. This help simplify the driver, and will allow setting DRIVER_OK earlier without losing config change notifications. Signed-off-by: Michael S. Tsirkin <[email protected]> Reviewed-by: Cornelia Huck <[email protected]> Signed-off-by: Rusty Russell <[email protected]>
2014-10-15virtio: defer config changed notificationsMichael S. Tsirkin2-9/+55
Defer config changed notifications that arrive during probe/scan/freeze/restore. This will allow drivers to set DRIVER_OK earlier, without worrying about racing with config change interrupts. This change will also benefit old hypervisors (before 2009) that send interrupts without checking DRIVER_OK: previously, the callback could race with driver-specific initialization. This will also help simplify drivers. Signed-off-by: Michael S. Tsirkin <[email protected]> Reviewed-by: Cornelia Huck <[email protected]> Signed-off-by: Rusty Russell <[email protected]> (cosmetic changes)
2014-10-15virtio-pci: move freeze/restore to virtio coreMichael S. Tsirkin3-52/+62
This is in preparation to extending config changed event handling in core. Wrapping these in an API also seems to make for a cleaner code. Signed-off-by: Michael S. Tsirkin <[email protected]> Reviewed-by: Cornelia Huck <[email protected]> Signed-off-by: Rusty Russell <[email protected]>
2014-10-15virtio: unify config_changed handlingMichael S. Tsirkin7-28/+17
Replace duplicated code in all transports with a single wrapper in virtio.c. The only functional change is in virtio_mmio.c: if a buggy device sends us an interrupt before driver is set, we previously returned IRQ_NONE, now we return IRQ_HANDLED. As this must not happen in practice, this does not look like a big deal. See also commit 3fff0179e33cd7d0a688dab65700c46ad089e934 virtio-pci: do not oops on config change if driver not loaded. for the original motivation behind the driver check. Signed-off-by: Michael S. Tsirkin <[email protected]> Reviewed-by: Cornelia Huck <[email protected]> Signed-off-by: Rusty Russell <[email protected]>
2014-10-15virtio_pci: fix virtio spec compliance on restoreMichael S. Tsirkin1-3/+30
On restore, virtio pci does the following: + set features + init vqs etc - device can be used at this point! + set ACKNOWLEDGE,DRIVER and DRIVER_OK status bits This is in violation of the virtio spec, which requires the following order: - ACKNOWLEDGE - DRIVER - init vqs - DRIVER_OK This behaviour will break with hypervisors that assume spec compliant behaviour. It seems like a good idea to have this patch applied to stable branches to reduce the support butden for the hypervisors. Cc: [email protected] Cc: Amit Shah <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]> Signed-off-by: Rusty Russell <[email protected]>
2014-10-15modules, lock around setting of MODULE_STATE_UNFORMEDPrarit Bhargava1-0/+2
A panic was seen in the following sitation. There are two threads running on the system. The first thread is a system monitoring thread that is reading /proc/modules. The second thread is loading and unloading a module (in this example I'm using my simple dummy-module.ko). Note, in the "real world" this occurred with the qlogic driver module. When doing this, the following panic occurred: ------------[ cut here ]------------ kernel BUG at kernel/module.c:3739! invalid opcode: 0000 [#1] SMP Modules linked in: binfmt_misc sg nfsv3 rpcsec_gss_krb5 nfsv4 dns_resolver nfs fscache intel_powerclamp coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel lrw igb gf128mul glue_helper iTCO_wdt iTCO_vendor_support ablk_helper ptp sb_edac cryptd pps_core edac_core shpchp i2c_i801 pcspkr wmi lpc_ich ioatdma mfd_core dca ipmi_si nfsd ipmi_msghandler auth_rpcgss nfs_acl lockd sunrpc xfs libcrc32c sr_mod cdrom sd_mod crc_t10dif crct10dif_common mgag200 syscopyarea sysfillrect sysimgblt i2c_algo_bit drm_kms_helper ttm isci drm libsas ahci libahci scsi_transport_sas libata i2c_core dm_mirror dm_region_hash dm_log dm_mod [last unloaded: dummy_module] CPU: 37 PID: 186343 Comm: cat Tainted: GF O-------------- 3.10.0+ #7 Hardware name: Intel Corporation S2600CP/S2600CP, BIOS RMLSDP.86I.00.29.D696.1311111329 11/11/2013 task: ffff8807fd2d8000 ti: ffff88080fa7c000 task.ti: ffff88080fa7c000 RIP: 0010:[<ffffffff810d64c5>] [<ffffffff810d64c5>] module_flags+0xb5/0xc0 RSP: 0018:ffff88080fa7fe18 EFLAGS: 00010246 RAX: 0000000000000003 RBX: ffffffffa03b5200 RCX: 0000000000000000 RDX: 0000000000001000 RSI: ffff88080fa7fe38 RDI: ffffffffa03b5000 RBP: ffff88080fa7fe28 R08: 0000000000000010 R09: 0000000000000000 R10: 0000000000000000 R11: 000000000000000f R12: ffffffffa03b5000 R13: ffffffffa03b5008 R14: ffffffffa03b5200 R15: ffffffffa03b5000 FS: 00007f6ae57ef740(0000) GS:ffff88101e7a0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000404f70 CR3: 0000000ffed48000 CR4: 00000000001407e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Stack: ffffffffa03b5200 ffff8810101e4800 ffff88080fa7fe70 ffffffff810d666c ffff88081e807300 000000002e0f2fbf 0000000000000000 ffff88100f257b00 ffffffffa03b5008 ffff88080fa7ff48 ffff8810101e4800 ffff88080fa7fee0 Call Trace: [<ffffffff810d666c>] m_show+0x19c/0x1e0 [<ffffffff811e4d7e>] seq_read+0x16e/0x3b0 [<ffffffff812281ed>] proc_reg_read+0x3d/0x80 [<ffffffff811c0f2c>] vfs_read+0x9c/0x170 [<ffffffff811c1a58>] SyS_read+0x58/0xb0 [<ffffffff81605829>] system_call_fastpath+0x16/0x1b Code: 48 63 c2 83 c2 01 c6 04 03 29 48 63 d2 eb d9 0f 1f 80 00 00 00 00 48 63 d2 c6 04 13 2d 41 8b 0c 24 8d 50 02 83 f9 01 75 b2 eb cb <0f> 0b 66 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 41 RIP [<ffffffff810d64c5>] module_flags+0xb5/0xc0 RSP <ffff88080fa7fe18> Consider the two processes running on the system. CPU 0 (/proc/modules reader) CPU 1 (loading/unloading module) CPU 0 opens /proc/modules, and starts displaying data for each module by traversing the modules list via fs/seq_file.c:seq_open() and fs/seq_file.c:seq_read(). For each module in the modules list, seq_read does op->start() <-- this is a pointer to m_start() op->show() <- this is a pointer to m_show() op->stop() <-- this is a pointer to m_stop() The m_start(), m_show(), and m_stop() module functions are defined in kernel/module.c. The m_start() and m_stop() functions acquire and release the module_mutex respectively. ie) When reading /proc/modules, the module_mutex is acquired and released for each module. m_show() is called with the module_mutex held. It accesses the module struct data and attempts to write out module data. It is in this code path that the above BUG_ON() warning is encountered, specifically m_show() calls static char *module_flags(struct module *mod, char *buf) { int bx = 0; BUG_ON(mod->state == MODULE_STATE_UNFORMED); ... The other thread, CPU 1, in unloading the module calls the syscall delete_module() defined in kernel/module.c. The module_mutex is acquired for a short time, and then released. free_module() is called without the module_mutex. free_module() then sets mod->state = MODULE_STATE_UNFORMED, also without the module_mutex. Some additional code is called and then the module_mutex is reacquired to remove the module from the modules list: /* Now we can delete it from the lists */ mutex_lock(&module_mutex); stop_machine(__unlink_module, mod, NULL); mutex_unlock(&module_mutex); This is the sequence of events that leads to the panic. CPU 1 is removing dummy_module via delete_module(). It acquires the module_mutex, and then releases it. CPU 1 has NOT set dummy_module->state to MODULE_STATE_UNFORMED yet. CPU 0, which is reading the /proc/modules, acquires the module_mutex and acquires a pointer to the dummy_module which is still in the modules list. CPU 0 calls m_show for dummy_module. The check in m_show() for MODULE_STATE_UNFORMED passed for dummy_module even though it is being torn down. Meanwhile CPU 1, which has been continuing to remove dummy_module without holding the module_mutex, now calls free_module() and sets dummy_module->state to MODULE_STATE_UNFORMED. CPU 0 now calls module_flags() with dummy_module and ... static char *module_flags(struct module *mod, char *buf) { int bx = 0; BUG_ON(mod->state == MODULE_STATE_UNFORMED); and BOOM. Acquire and release the module_mutex lock around the setting of MODULE_STATE_UNFORMED in the teardown path, which should resolve the problem. Testing: In the unpatched kernel I can panic the system within 1 minute by doing while (true) do insmod dummy_module.ko; rmmod dummy_module.ko; done and while (true) do cat /proc/modules; done in separate terminals. In the patched kernel I was able to run just over one hour without seeing any issues. I also verified the output of panic via sysrq-c and the output of /proc/modules looks correct for all three states for the dummy_module. dummy_module 12661 0 - Unloading 0xffffffffa03a5000 (OE-) dummy_module 12661 0 - Live 0xffffffffa03bb000 (OE) dummy_module 14015 1 - Loading 0xffffffffa03a5000 (OE+) Signed-off-by: Prarit Bhargava <[email protected]> Reviewed-by: Oleg Nesterov <[email protected]> Signed-off-by: Rusty Russell <[email protected]> Cc: [email protected]
Powered by cgit, Gruvboxed by Blaster4385.