| Message ID | 20200901184445.1736658-1-saravanak@google.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2] driver core: Fix device_pm_lock() locking for device links | expand |
> Subject: [PATCH v2] driver core: Fix device_pm_lock() locking for device links > > This commit fixes two issues: > > 1. The lockdep warning reported by Dong Aisheng <dongas86@gmail.com> > [1]. > > It is a warning about a cycle (dpm_list_mtx --> kn->active#3 --> fw_lock) that > was introduced when device-link devices were added to expose device link > information in sysfs. > > The patch that "introduced" this cycle can't be reverted because it's fixes a > real SRCU issue and also ensures that the device-link device is deleted as > soon as the device-link is deleted. This is important to avoid sysfs name > collisions if the device-link is create again immediately (this can happen a lot > with deferred probing). > > 2. Inconsistency in grabbing device_pm_lock() during device link deletion > > Some device link deletion code paths grab device_pm_lock(), while others > don't. The device_pm_lock() is grabbed during device_link_add() because it > checks if the supplier is in the dpm_list and also reorders the dpm_list. > However, when a device link is deleted, it does not do either of those and > therefore device_pm_lock() is not necessary. Dropping the device_pm_lock() > in all the device link deletion paths removes the inconsistency in locking. > > Thanks to Stephen Boyd for helping me understand the lockdep splat. > > Fixes: 843e600b8a2b ("driver core: Fix sleeping in invalid context during > device link deletion") [1] - > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.ke > rnel.org%2Flkml%2FCAA%2BhA%3DS4eAreb7vo69LAXSk2t5%3DDEKNxHaiY1 > wSpk4xTp9urLg%40mail.gmail.com%2F&data=02%7C01%7Cpeng.fan%4 > 0nxp.com%7Cc07e23dccfa84d96b17808d84ea71bb9%7C686ea1d3bc2b4c6f > a92cd99c5c301635%7C0%7C0%7C637345826922594698&sdata=X0Pzb > ni5QcjxOCWkfR9uvxRcfvpzPQSNMmk%2BJf93dYI%3D&reserved=0 > Reported-by: Dong Aisheng <dongas86@gmail.com> > Signed-off-by: Saravana Kannan <saravanak@google.com> Tested-by: Peng Fan <peng.fan@nxp.com> Thanks, Peng. > --- > > Cc'ing everyone from the original thread [1] > > -Saravana > > drivers/base/core.c | 4 ---- > 1 file changed, 4 deletions(-) > > diff --git a/drivers/base/core.c b/drivers/base/core.c index > f6f620aa9408..07e5ceb40bb1 100644 > --- a/drivers/base/core.c > +++ b/drivers/base/core.c > @@ -807,9 +807,7 @@ static void device_link_put_kref(struct device_link > *link) void device_link_del(struct device_link *link) { > device_links_write_lock(); > - device_pm_lock(); > device_link_put_kref(link); > - device_pm_unlock(); > device_links_write_unlock(); > } > EXPORT_SYMBOL_GPL(device_link_del); > @@ -830,7 +828,6 @@ void device_link_remove(void *consumer, struct > device *supplier) > return; > > device_links_write_lock(); > - device_pm_lock(); > > list_for_each_entry(link, &supplier->links.consumers, s_node) { > if (link->consumer == consumer) { > @@ -839,7 +836,6 @@ void device_link_remove(void *consumer, struct > device *supplier) > } > } > > - device_pm_unlock(); > device_links_write_unlock(); > } > EXPORT_SYMBOL_GPL(device_link_remove); > -- > 2.28.0.402.g5ffc5be6b7-goog
Quoting Saravana Kannan (2020-09-01 11:44:44) > This commit fixes two issues: > > 1. The lockdep warning reported by Dong Aisheng <dongas86@gmail.com> [1]. > > It is a warning about a cycle (dpm_list_mtx --> kn->active#3 --> fw_lock) > that was introduced when device-link devices were added to expose device > link information in sysfs. > > The patch that "introduced" this cycle can't be reverted because it's fixes > a real SRCU issue and also ensures that the device-link device is deleted > as soon as the device-link is deleted. This is important to avoid sysfs > name collisions if the device-link is create again immediately (this can > happen a lot with deferred probing). Just curious, why are there sysfs name collisions for device links? Shouldn't the device link device be named something like "devlink<N>" with some IDA incrementing N so that collisions can never happen? If they were always unique then presumably it would be OK to keep using SRCU?
diff --git a/drivers/base/core.c b/drivers/base/core.c index f6f620aa9408..07e5ceb40bb1 100644 --- a/drivers/base/core.c +++ b/drivers/base/core.c @@ -807,9 +807,7 @@ static void device_link_put_kref(struct device_link *link) void device_link_del(struct device_link *link) { device_links_write_lock(); - device_pm_lock(); device_link_put_kref(link); - device_pm_unlock(); device_links_write_unlock(); } EXPORT_SYMBOL_GPL(device_link_del); @@ -830,7 +828,6 @@ void device_link_remove(void *consumer, struct device *supplier) return; device_links_write_lock(); - device_pm_lock(); list_for_each_entry(link, &supplier->links.consumers, s_node) { if (link->consumer == consumer) { @@ -839,7 +836,6 @@ void device_link_remove(void *consumer, struct device *supplier) } } - device_pm_unlock(); device_links_write_unlock(); } EXPORT_SYMBOL_GPL(device_link_remove);
This commit fixes two issues: 1. The lockdep warning reported by Dong Aisheng <dongas86@gmail.com> [1]. It is a warning about a cycle (dpm_list_mtx --> kn->active#3 --> fw_lock) that was introduced when device-link devices were added to expose device link information in sysfs. The patch that "introduced" this cycle can't be reverted because it's fixes a real SRCU issue and also ensures that the device-link device is deleted as soon as the device-link is deleted. This is important to avoid sysfs name collisions if the device-link is create again immediately (this can happen a lot with deferred probing). 2. Inconsistency in grabbing device_pm_lock() during device link deletion Some device link deletion code paths grab device_pm_lock(), while others don't. The device_pm_lock() is grabbed during device_link_add() because it checks if the supplier is in the dpm_list and also reorders the dpm_list. However, when a device link is deleted, it does not do either of those and therefore device_pm_lock() is not necessary. Dropping the device_pm_lock() in all the device link deletion paths removes the inconsistency in locking. Thanks to Stephen Boyd for helping me understand the lockdep splat. Fixes: 843e600b8a2b ("driver core: Fix sleeping in invalid context during device link deletion") [1] - https://lore.kernel.org/lkml/CAA+hA=S4eAreb7vo69LAXSk2t5=DEKNxHaiY1wSpk4xTp9urLg@mail.gmail.com/ Reported-by: Dong Aisheng <dongas86@gmail.com> Signed-off-by: Saravana Kannan <saravanak@google.com> --- Cc'ing everyone from the original thread [1] -Saravana drivers/base/core.c | 4 ---- 1 file changed, 4 deletions(-)