user/sven/linux.git/drivers/base, branch v3.10.44

drivercore: deferral race condition fix

2014-06-07T20:25:31Z

commit 58b116bce13612e5aa6fcd49ecbd4cf8bb59e835 upstream. When the kernel is built with CONFIG_PREEMPT it is possible to reach a state when all modules loaded but some driver still stuck in the deferred list and there is a need for external event to kick the deferred queue to probe these drivers. The issue has been observed on embedded systems with CONFIG_PREEMPT enabled, audio support built as modules and using nfsroot for root filesystem. The following log fragment shows such sequence when all audio modules were loaded but the sound card is not present since the machine driver has failed to probe due to missing dependency during it's probe. The board is am335x-evmsk (McASP<->tlv320aic3106 codec) with davinci-evm machine driver: ... [ 12.615118] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: ENTER [ 12.719969] davinci_evm sound.3: davinci_evm_probe: ENTER [ 12.725753] davinci_evm sound.3: davinci_evm_probe: snd_soc_register_card [ 12.753846] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: snd_soc_register_component [ 12.922051] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: snd_soc_register_component DONE [ 12.950839] davinci_evm sound.3: ASoC: platform (null) not registered [ 12.957898] davinci_evm sound.3: davinci_evm_probe: snd_soc_register_card DONE (-517) [ 13.099026] davinci-mcasp 4803c000.mcasp: Kicking the deferred list [ 13.177838] davinci-mcasp 4803c000.mcasp: really_probe: probe_count = 2 [ 13.194130] davinci_evm sound.3: snd_soc_register_card failed (-517) [ 13.346755] davinci_mcasp_driver_init: LEAVE [ 13.377446] platform sound.3: Driver davinci_evm requests probe deferral [ 13.592527] platform sound.3: really_probe: probe_count = 0 In the log the machine driver enters it's probe at 12.719969 (this point it has been removed from the deferred lists). McASP driver already executing it's probing (since 12.615118). The machine driver tries to construct the sound card (12.950839) but did not found one of the components so it fails. After this McASP driver registers all the ASoC components (the machine driver still in it's probe function after it failed to construct the card) and the deferred work is prepared at 13.099026 (note that this time the machine driver is not in the lists so it is not going to be handled when the work is executing). Lastly the machine driver exit from it's probe and the core places it to the deferred list but there will be no other driver going to load and the deferred queue is not going to be kicked again - till we have external event like connecting USB stick, etc. The proposed solution is to try the deferred queue once more when the last driver is asking for deferring and we had drivers loaded while this last driver was probing. This way we can avoid drivers stuck in the deferred queue. Signed-off-by: Grant Likely Reviewed-by: Peter Ujfalusi Tested-by: Peter Ujfalusi Acked-by: Greg Kroah-Hartman Cc: Mark Brown Signed-off-by: Greg Kroah-Hartman

topology: Fix compilation warning when not in SMP

2014-06-07T20:25:29Z

commit 53974e06603977f348ed978d75c426b0532daa67 upstream. The topology_##name() macro does not use its argument when CONFIG_SMP is not set, as it ultimately calls the cpu_data() macro. So we avoid maintaining a possibly unused `cpu' variable, to avoid the following compilation warning: drivers/base/topology.c: In function ‘show_physical_package_id’: drivers/base/topology.c:103:118: warning: unused variable ‘cpu’ [-Wunused-variable] define_id_show_func(physical_package_id); drivers/base/topology.c: In function ‘show_core_id’: drivers/base/topology.c:106:106: warning: unused variable ‘cpu’ [-Wunused-variable] define_id_show_func(core_id); This can be seen with e.g. x86 defconfig and CONFIG_SMP not set. Signed-off-by: Vincent Stehlé Signed-off-by: Greg Kroah-Hartman

PM / runtime: Use pm_runtime_put_sync() in __device_release_driver()

2013-12-04T18:56:59Z

commit baab52ded242c35a2290e1fa82e0cc147d0d8c1a upstream. Commit fa180eb448fa (PM / Runtime: Idle devices asynchronously after probe|release) modified __device_release_driver() to call pm_runtime_put(dev) instead of pm_runtime_put_sync(dev) before detaching the driver from the device. However, that was a mistake, because pm_runtime_put(dev) causes rpm_idle() to be queued up and the driver may be gone already when that function is executed. That breaks the assumptions the drivers have the right to make about the core's behavior on the basis of the existing documentation and actually causes problems to happen, so revert that part of commit fa180eb448fa and restore the previous behavior of __device_release_driver(). Reported-by: Tomi Valkeinen Fixes: fa180eb448fa (PM / Runtime: Idle devices asynchronously after probe|release) Signed-off-by: Rafael J. Wysocki Acked-by: Kevin Hilman Acked-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman

driver core : Fix use after free of dev->parent in device_shutdown

2013-10-05T14:13:11Z

commit f123db8e9d6c84c863cb3c44d17e61995dc984fb upstream. The put_device(dev) at the bottom of the loop of device_shutdown may result in the dev being cleaned up. In device_create_release, the dev is kfreed. However, device_shutdown attempts to use the dev pointer again after put_device by referring to dev->parent. Copy the parent pointer instead to avoid this condition. This bug was found on Chromium OS's chromeos-3.8, which is based on v3.8.11. See bug report : https://code.google.com/p/chromium/issues/detail?id=297842 This can easily be reproduced when shutting down with hidraw devices that report battery condition. Two examples are the HP Bluetooth Mouse X4000b and the Apple Magic Mouse. For example, with the magic mouse : The dev in question is "hidraw0" dev->parent is "magicmouse" In the course of the shutdown for this device, the input event cleanup calls a put on hidraw0, decrementing its reference count. When we finally get to put_device(dev) in device_shutdown, kobject_cleanup is called and device_create_release does kfree(dev). dev->parent is no longer valid, and we may crash in put_device(dev->parent). This change should be applied on any kernel with this change : d1c6c030fcec6f860d9bb6c632a3ebe62e28440b Signed-off-by: Benson Leung Reviewed-by: Ming Lei Signed-off-by: Greg Kroah-Hartman

regmap: rbtree: Fix overlapping rbnodes.

2013-09-08T05:10:00Z

commit 4e67fb5f5e336250db944921e3c68057d6203034 upstream. Avoid overlapping register regions by making the initial blklen of a new node 1. If a register write occurs to a yet uncached register, that is lower than but near an existing node's base_reg, a new node is created and it's blklen is set to an arbitrary value (sizeof(*rbnode)). That may cause this node to overlap with another node. Those nodes should be merged, but this merge doesn't happen yet, so this patch at least makes the initial blklen small enough to avoid hitting the wrong node, which may otherwise lead to severe breakage. Signed-off-by: David Jander Signed-off-by: Mark Brown Signed-off-by: Zhouping Liu Signed-off-by: Greg Kroah-Hartman

drivers/base/memory.c: fix show_mem_removable() to handle missing sections

2013-09-08T05:09:58Z

commit 21ea9f5ace3a7317cc3ba1fbc749758021a83136 upstream. "cat /sys/devices/system/memory/memory*/removable" crashed the system. The problem is that show_mem_removable() is passing a bad pfn to is_mem_section_removable(), which causes if (!node_online(page_to_nid(page))) to blow up. Why is it passing in a bad pfn? The reason is that show_mem_removable() will loop sections_per_block times. sections_per_block is 16, but mem->section_count is 8, indicating holes in this memory block. Checking that the memory section is present before checking to see if the memory section is removable fixes the problem. harp5-sys:~ # cat /sys/devices/system/memory/memory*/removable 0 1 1 1 1 1 1 1 1 1 1 1 1 1 BUG: unable to handle kernel paging request at ffffea00c3200000 IP: [] is_pageblock_removable_nolock+0x1/0x90 PGD 83ffd4067 PUD 37bdfce067 PMD 0 Oops: 0000 [#1] SMP Modules linked in: autofs4 binfmt_misc rdma_ucm rdma_cm iw_cm ib_addr ib_srp scsi_transport_srp scsi_tgt ib_ipoib ib_cm ib_uverbs ib_umad iw_cxgb3 cxgb3 mdio mlx4_en mlx4_ib ib_sa mlx4_core ib_mthca ib_mad ib_core fuse nls_iso8859_1 nls_cp437 vfat fat joydev loop hid_generic usbhid hid hwperf(O) numatools(O) dm_mod iTCO_wdt ipv6 iTCO_vendor_support igb i2c_i801 ioatdma i2c_algo_bit ehci_pci pcspkr lpc_ich i2c_core ehci_hcd ptp sg mfd_core dca rtc_cmos pps_core mperf button xhci_hcd sd_mod crc_t10dif usbcore usb_common scsi_dh_emc scsi_dh_hp_sw scsi_dh_alua scsi_dh_rdac scsi_dh gru(O) xvma(O) xfs crc32c libcrc32c thermal sata_nv processor piix mptsas mptscsih scsi_transport_sas mptbase megaraid_sas fan thermal_sys hwmon ext3 jbd ata_piix ahci libahci libata scsi_mod CPU: 4 PID: 5991 Comm: cat Tainted: G O 3.11.0-rc5-rja-uv+ #10 Hardware name: SGI UV2000/ROMLEY, BIOS SGI UV 2000/3000 series BIOS 01/15/2013 task: ffff88081f034580 ti: ffff880820022000 task.ti: ffff880820022000 RIP: 0010:[] [] is_pageblock_removable_nolock+0x1/0x90 RSP: 0018:ffff880820023df8 EFLAGS: 00010287 RAX: 0000000000040000 RBX: ffffea00c3200000 RCX: 0000000000000004 RDX: ffffea00c30b0000 RSI: 00000000001c0000 RDI: ffffea00c3200000 RBP: ffff880820023e38 R08: 0000000000000000 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000001 R12: ffffea00c33c0000 R13: 0000160000000000 R14: 6db6db6db6db6db7 R15: 0000000000000001 FS: 00007ffff7fb2700(0000) GS:ffff88083fc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffea00c3200000 CR3: 000000081b954000 CR4: 00000000000407e0 Call Trace: show_mem_removable+0x41/0x70 dev_attr_show+0x2a/0x60 sysfs_read_file+0xf7/0x1c0 vfs_read+0xc8/0x130 SyS_read+0x5d/0xa0 system_call_fastpath+0x16/0x1b Signed-off-by: Russ Anderson Cc: "Rafael J. Wysocki" Cc: Yinghai Lu Reviewed-by: Yasuaki Ishimatsu Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

regmap: cache: Make sure to sync the last register in a block

2013-08-15T05:59:06Z

commit 2d49b5987561e480bdbd8692b27fc5f49a1e2f0b upstream. regcache_sync_block_raw_flush() expects the address of the register after last register that needs to be synced as its parameter. But the last call to regcache_sync_block_raw_flush() in regcache_sync_block_raw() passes the address of the last register in the block. This effectively always skips over the last register in a block, even if it needs to be synced. In order to fix it increase the address by one register. The issue was introduced in commit 75a5f89 ("regmap: cache: Write consecutive registers in a single block write"). Signed-off-by: Lars-Peter Clausen Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman

regmap: cache: bail in regmap_async_complete() for bus-less maps

2013-08-04T08:50:58Z

commit f2e055e7c9c6084bfbaa68701e52562acf96419e upstream. Commit f8bd822cb ("regmap: cache: Factor out block sync") made regcache_rbtree_sync() call regmap_async_complete(), which in turn does not check for map->bus before dereferencing it. This causes a NULL pointer dereference on bus-less maps. Signed-off-by: Daniel Mack Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman

firmware loader: fix use-after-free by double abort

2013-06-18T17:41:55Z

fw_priv->buf is accessed in both request_firmware_load() and writing to sysfs file of 'loading' context, but not protected by 'fw_lock' entirely. The patch makes sure that access on 'fw_priv->buf' is protected by the lock. So fixes the double abort problem reported by nirinA raseliarison: http://lkml.org/lkml/2013/6/14/188 Reported-and-tested-by: nirinA raseliarison Cc: Guenter Roeck Cc: Bjorn Helgaas Cc: stable # 3.9 Signed-off-by: Ming Lei Signed-off-by: Greg Kroah-Hartman

Merge remote-tracking branch 'regmap/fix/debugfs' into regmap-linus

2013-06-03T17:07:38Z