linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] driver core: Fix locking bug in deferred_probe_timeout_work_func()
@ 2021-04-12 18:09 Saravana Kannan
  2021-04-15 13:51 ` Greg Kroah-Hartman
  0 siblings, 1 reply; 2+ messages in thread
From: Saravana Kannan @ 2021-04-12 18:09 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Rafael J. Wysocki
  Cc: Saravana Kannan, stable, kernel-team, linux-kernel

commit eed6e41813deb9ee622cd9242341f21430d7789f upstream.

list_for_each_entry_safe() is only useful if we are deleting nodes in a
linked list within the loop. It doesn't protect against other threads
adding/deleting nodes to the list in parallel. We need to grab
deferred_probe_mutex when traversing the deferred_probe_pending_list.

Cc: stable@vger.kernel.org
Fixes: 25b4e70dcce9 ("driver core: allow stopping deferred probe after init")
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20210402040342.2944858-2-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
Hi Greg,

This should apply cleanly to 4.19 and 5.4 if you think this should be
picked up.

-Saravana

 drivers/base/dd.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 4ba9231a6be8..26ba7a99b7d5 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -254,14 +254,16 @@ int driver_deferred_probe_check_state(struct device *dev)
 
 static void deferred_probe_timeout_work_func(struct work_struct *work)
 {
-	struct device_private *private, *p;
+	struct device_private *p;
 
 	deferred_probe_timeout = 0;
 	driver_deferred_probe_trigger();
 	flush_work(&deferred_probe_work);
 
-	list_for_each_entry_safe(private, p, &deferred_probe_pending_list, deferred_probe)
-		dev_info(private->device, "deferred probe pending");
+	mutex_lock(&deferred_probe_mutex);
+	list_for_each_entry(p, &deferred_probe_pending_list, deferred_probe)
+		dev_info(p->device, "deferred probe pending\n");
+	mutex_unlock(&deferred_probe_mutex);
 }
 static DECLARE_DELAYED_WORK(deferred_probe_timeout_work, deferred_probe_timeout_work_func);
 
-- 
2.31.1.295.g9ea45b61b8-goog


^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [PATCH] driver core: Fix locking bug in deferred_probe_timeout_work_func()
  2021-04-12 18:09 [PATCH] driver core: Fix locking bug in deferred_probe_timeout_work_func() Saravana Kannan
@ 2021-04-15 13:51 ` Greg Kroah-Hartman
  0 siblings, 0 replies; 2+ messages in thread
From: Greg Kroah-Hartman @ 2021-04-15 13:51 UTC (permalink / raw)
  To: Saravana Kannan; +Cc: Rafael J. Wysocki, stable, kernel-team, linux-kernel

On Mon, Apr 12, 2021 at 11:09:06AM -0700, Saravana Kannan wrote:
> commit eed6e41813deb9ee622cd9242341f21430d7789f upstream.
> 
> list_for_each_entry_safe() is only useful if we are deleting nodes in a
> linked list within the loop. It doesn't protect against other threads
> adding/deleting nodes to the list in parallel. We need to grab
> deferred_probe_mutex when traversing the deferred_probe_pending_list.
> 
> Cc: stable@vger.kernel.org
> Fixes: 25b4e70dcce9 ("driver core: allow stopping deferred probe after init")
> Signed-off-by: Saravana Kannan <saravanak@google.com>
> Link: https://lore.kernel.org/r/20210402040342.2944858-2-saravanak@google.com
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
> Hi Greg,
> 
> This should apply cleanly to 4.19 and 5.4 if you think this should be
> picked up.

thanks, now queued up.

greg k-h

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2021-04-15 13:51 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-04-12 18:09 [PATCH] driver core: Fix locking bug in deferred_probe_timeout_work_func() Saravana Kannan
2021-04-15 13:51 ` Greg Kroah-Hartman

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).