linux/drivers/base/dd.c, branch v5.17

driver core: Free DMA range map when device is released

2022-02-22T07:40:02Z

When unbinding/binding a driver with DMA mapped memory, the DMA map is not freed before the driver is reloaded. This leads to a memory leak when the DMA map is overwritten when reprobing the driver. This can be reproduced with a platform driver having a dma-range: dummy { ... #address-cells = <0x2>; #size-cells = <0x2>; ranges; dma-ranges = <...>; ... }; and then unbinding/binding it: ~# echo soc:dummy >/sys/bus/platform/drivers//unbind DMA map object 0xffffff800b0ae540 still being held by &pdev->dev ~# echo soc:dummy >/sys/bus/platform/drivers//bind ~# echo scan > /sys/kernel/debug/kmemleak ~# cat /sys/kernel/debug/kmemleak unreferenced object 0xffffff800b0ae540 (size 64): comm "sh", pid 833, jiffies 4295174550 (age 2535.352s) hex dump (first 32 bytes): 00 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 80 00 00 00 00 00 00 00 80 00 00 00 00 ................ backtrace: [] create_object.isra.0+0x108/0x344 [] kmemleak_alloc+0x8c/0xd0 [] __kmalloc+0x440/0x6f0 [] of_dma_get_range+0x124/0x220 [] of_dma_configure_id+0x40/0x2d0 [] platform_dma_configure+0x5c/0xa4 [] really_probe+0x8c/0x514 [] __driver_probe_device+0x9c/0x19c [] device_driver_attach+0x54/0xbc [] bind_store+0xc4/0x120 [] drv_attr_store+0x30/0x44 [] sysfs_kf_write+0x50/0x60 [] kernfs_fop_write_iter+0x124/0x1b4 [] new_sync_write+0xdc/0x160 [] vfs_write+0x23c/0x2a0 [] ksys_write+0x64/0xec To prevent this we should free the dma_range_map when the device is released. Fixes: e0d072782c73 ("dma-mapping: introduce DMA range map, supplanting dma_pfn_offset") Cc: stable Suggested-by: Rob Herring Reviewed-by: Rob Herring Signed-off-by: Mårten Lindahl Link: https://lore.kernel.org/r/20220216094128.4025861-1-marten.lindahl@axis.com Signed-off-by: Greg Kroah-Hartman

driver core: Make bus notifiers in right order in really_probe()

2022-01-06T14:47:41Z

If a driver cannot be bound to a device, the correct bus notifier order should be: - BUS_NOTIFY_BIND_DRIVER: driver is about to be bound - BUS_NOTIFY_DRIVER_NOT_BOUND: driver failed to be bound or no notifier if the failure happens before the actual binding. The really_probe() notifies a BUS_NOTIFY_DRIVER_NOT_BOUND event without a BUS_NOTIFY_BIND_DRIVER if .dma_configure() returns failure. This change makes the notifiers in order. Signed-off-by: Lu Baolu Link: https://lore.kernel.org/r/20211231033901.2168664-3-baolu.lu@linux.intel.com Signed-off-by: Greg Kroah-Hartman

driver core: Move driver_sysfs_remove() after driver_sysfs_add()

2022-01-06T14:47:41Z

The driver_sysfs_remove() should be called after driver_sysfs_add() in really_probe(). The out-of-order driver_sysfs_remove() tries to remove some nonexistent nodes under the device and driver sysfs nodes. This is allowed, hence this change doesn't fix any problem, just a cleanup. Signed-off-by: Lu Baolu Link: https://lore.kernel.org/r/20211231033901.2168664-2-baolu.lu@linux.intel.com Signed-off-by: Greg Kroah-Hartman

Merge 5.14-rc5 into driver-core-next

2021-08-09T07:03:47Z

We need the driver core fixes in here as well. Signed-off-by: Greg Kroah-Hartman

drivers core: Fix oops when driver probe fails

2021-07-27T12:44:43Z

dma_range_map is freed to early, which might cause an oops when a driver probe fails. Call trace: is_free_buddy_page+0xe4/0x1d4 __free_pages+0x2c/0x88 dma_free_contiguous+0x64/0x80 dma_direct_free+0x38/0xb4 dma_free_attrs+0x88/0xa0 dmam_release+0x28/0x34 release_nodes+0x78/0x8c devres_release_all+0xa8/0x110 really_probe+0x118/0x2d0 __driver_probe_device+0xc8/0xe0 driver_probe_device+0x54/0xec __driver_attach+0xe0/0xf0 bus_for_each_dev+0x7c/0xc8 driver_attach+0x30/0x3c bus_add_driver+0x17c/0x1c4 driver_register+0xc0/0xf8 __platform_driver_register+0x34/0x40 ... This issue is introduced by commit d0243bbd5dd3 ("drivers core: Free dma_range_map when driver probe failed"). It frees dma_range_map before the call to devres_release_all, which is too early. The solution is to free dma_range_map only after devres_release_all. Fixes: d0243bbd5dd3 ("drivers core: Free dma_range_map when driver probe failed") Cc: stable Signed-off-by: Filip Schauer Link: https://lore.kernel.org/r/20210727112311.GA7645@DESKTOP-E8BN1B0.localdomain Signed-off-by: Greg Kroah-Hartman

driver core: Fix error return code in really_probe()

2021-07-21T14:16:23Z

In the case of error handling, the error code returned by the subfunction should be propagated instead of 0. Fixes: 1901fb2604fb ("Driver core: fix "driver" symlink timing") Fixes: 23b6904442d0 ("driver core: add dev_groups to all drivers") Fixes: 8fd456ec0cf0 ("driver core: Add state_synced sysfs file for devices that support it") Reported-by: Hulk Robot Signed-off-by: Zhen Lei Link: https://lore.kernel.org/r/20210707074301.2722-1-thunder.leizhen@huawei.com Signed-off-by: Greg Kroah-Hartman

driver core: Export device_driver_attach()

2021-06-21T21:29:24Z

This is intended as a replacement API for device_bind_driver(). It has at least the following benefits: - Internal locking. Few of the users of device_bind_driver() follow the locking rules - Calls device driver probe() internally. Notably this means that devm support for probe works correctly as probe() error will call devres_release_all() - struct device_driver -> dev_groups is supported - Simplified calling convention, no need to manually call probe(). The general usage is for situations that already know what driver to bind and need to ensure the bind is synchronized with other logic. Call device_driver_attach() after device_add(). If probe() returns a failure then this will be preserved up through to the error return of device_driver_attach(). Signed-off-by: Jason Gunthorpe Signed-off-by: Christoph Hellwig Reviewed-by: Cornelia Huck Reviewed-by: Greg Kroah-Hartman Link: https://lore.kernel.org/r/20210617142218.1877096-6-hch@lst.de Signed-off-by: Alex Williamson

driver core: Don't return EPROBE_DEFER to userspace during sysfs bind

2021-06-21T21:29:24Z

EPROBE_DEFER is an internal kernel error code and it should not be leaked to userspace via the bind_store() sysfs. Userspace doesn't have this constant and cannot understand it. Further, it doesn't really make sense to have userspace trigger a deferred probe via bind_store(), which could eventually succeed, while simultaneously returning an error back. Resolve this by splitting driver_probe_device so that the version used by the sysfs binding that turns EPROBE_DEFER into -EAGAIN, while the one used for internally binding keeps the error code, and calls driver_deferred_probe_add where needed. This also allows to nicely split out the defer_all_probes / probe_count checks so that they actually allow for full device_{block,unblock}_probing protection while not bothering the sysfs bind case. Signed-off-by: Christoph Hellwig Reviewed-by: Cornelia Huck Reviewed-by: Greg Kroah-Hartman Link: https://lore.kernel.org/r/20210617142218.1877096-5-hch@lst.de Signed-off-by: Alex Williamson

driver core: Flow the return code from ->probe() through to sysfs bind

2021-06-21T21:29:24Z

Currently really_probe() returns 1 on success and 0 if the probe() call fails. This return code arrangement is designed to be useful for __device_attach_driver() which is walking the device list and trying every driver. 0 means to keep trying. However, it is not useful for the other places that call through to really_probe() that do actually want to see the probe() return code. For instance bind_store() would be better to return the actual error code from the driver's probe method, not discarding it and returning -ENODEV. Reorganize things so that really_probe() returns the error code from ->probe as a (inverted) positive number, and 0 for successful attach. With this, __device_attach_driver can ignore the (positive) probe errors, return 1 to exit the loop for a successful binding and pass on the other negative errors, while device_driver_attach simplify inverts the positive errors and returns all errors to the sysfs code. Signed-off-by: Christoph Hellwig Reviewed-by: Greg Kroah-Hartman Reviewed-by: Cornelia Huck Link: https://lore.kernel.org/r/20210617142218.1877096-4-hch@lst.de Signed-off-by: Alex Williamson

driver core: Better distinguish probe errors in really_probe

2021-06-21T21:29:24Z

really_probe tries to special case errors from ->probe, but due to all other initialization added to the function over time now a lot of internal errors hit that code path as well. Untangle that by adding a new probe_err local variable and apply the special casing only to that. Signed-off-by: Christoph Hellwig Reviewed-by: Cornelia Huck Reviewed-by: Greg Kroah-Hartman Reviewed-by: Kirti Wankhede Link: https://lore.kernel.org/r/20210617142218.1877096-3-hch@lst.de Signed-off-by: Alex Williamson