All of lore.kernel.org
 help / color / mirror / Atom feed
* [RFC PATCH] net: rtnetlink: remove local list in __linkwatch_run_queue()
@ 2023-12-04 20:19 Johannes Berg
  2023-12-05 11:22 ` Jiri Pirko
  0 siblings, 1 reply; 3+ messages in thread
From: Johannes Berg @ 2023-12-04 20:19 UTC (permalink / raw)
  To: netdev; +Cc: Johannes Berg

From: Johannes Berg <johannes.berg@intel.com>

Due to linkwatch_forget_dev() (and perhaps others?) checking for
list_empty(&dev->link_watch_list), we must have all manipulations
of even the local on-stack list 'wrk' here under spinlock, since
even that list can be reached otherwise via dev->link_watch_list.

This is already the case, but makes this a bit counter-intuitive,
often local lists are used to _not_ have to use locking for their
local use.

Remove the local list as it doesn't seem to serve any purpose.
While at it, move a variable declaration into the loop using it.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
 net/core/link_watch.c | 13 ++++---------
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/net/core/link_watch.c b/net/core/link_watch.c
index c469d1c4db5d..ed3e5391fa79 100644
--- a/net/core/link_watch.c
+++ b/net/core/link_watch.c
@@ -192,8 +192,6 @@ static void __linkwatch_run_queue(int urgent_only)
 #define MAX_DO_DEV_PER_LOOP	100
 
 	int do_dev = MAX_DO_DEV_PER_LOOP;
-	struct net_device *dev;
-	LIST_HEAD(wrk);
 
 	/* Give urgent case more budget */
 	if (urgent_only)
@@ -215,11 +213,11 @@ static void __linkwatch_run_queue(int urgent_only)
 	clear_bit(LW_URGENT, &linkwatch_flags);
 
 	spin_lock_irq(&lweventlist_lock);
-	list_splice_init(&lweventlist, &wrk);
+	while (!list_empty(&lweventlist) && do_dev > 0) {
+		struct net_device *dev;
 
-	while (!list_empty(&wrk) && do_dev > 0) {
-
-		dev = list_first_entry(&wrk, struct net_device, link_watch_list);
+		dev = list_first_entry(&lweventlist, struct net_device,
+				       link_watch_list);
 		list_del_init(&dev->link_watch_list);
 
 		if (!netif_device_present(dev) ||
@@ -237,9 +235,6 @@ static void __linkwatch_run_queue(int urgent_only)
 		spin_lock_irq(&lweventlist_lock);
 	}
 
-	/* Add the remaining work back to lweventlist */
-	list_splice_init(&wrk, &lweventlist);
-
 	if (!list_empty(&lweventlist))
 		linkwatch_schedule_work(0);
 	spin_unlock_irq(&lweventlist_lock);
-- 
2.43.0


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

* Re: [RFC PATCH] net: rtnetlink: remove local list in __linkwatch_run_queue()
  2023-12-04 20:19 [RFC PATCH] net: rtnetlink: remove local list in __linkwatch_run_queue() Johannes Berg
@ 2023-12-05 11:22 ` Jiri Pirko
  2023-12-05 11:24   ` Johannes Berg
  0 siblings, 1 reply; 3+ messages in thread
From: Jiri Pirko @ 2023-12-05 11:22 UTC (permalink / raw)
  To: Johannes Berg; +Cc: netdev, Johannes Berg

Mon, Dec 04, 2023 at 09:19:53PM CET, johannes@sipsolutions.net wrote:
>From: Johannes Berg <johannes.berg@intel.com>

Why rfc?


>
>Due to linkwatch_forget_dev() (and perhaps others?) checking for
>list_empty(&dev->link_watch_list), we must have all manipulations
>of even the local on-stack list 'wrk' here under spinlock, since
>even that list can be reached otherwise via dev->link_watch_list.
>
>This is already the case, but makes this a bit counter-intuitive,
>often local lists are used to _not_ have to use locking for their
>local use.
>
>Remove the local list as it doesn't seem to serve any purpose.
>While at it, move a variable declaration into the loop using it.
>
>Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Reviewed-by: Jiri Pirko <jiri@nvidia.com>

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

* Re: [RFC PATCH] net: rtnetlink: remove local list in __linkwatch_run_queue()
  2023-12-05 11:22 ` Jiri Pirko
@ 2023-12-05 11:24   ` Johannes Berg
  0 siblings, 0 replies; 3+ messages in thread
From: Johannes Berg @ 2023-12-05 11:24 UTC (permalink / raw)
  To: Jiri Pirko; +Cc: netdev

On Tue, 2023-12-05 at 12:22 +0100, Jiri Pirko wrote:
> Mon, Dec 04, 2023 at 09:19:53PM CET, johannes@sipsolutions.net wrote:
> > From: Johannes Berg <johannes.berg@intel.com>
> 
> Why rfc?

I thought maybe someone could come up with a reason it actually makes
sense? :)

johannes

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

end of thread, other threads:[~2023-12-05 11:24 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-12-04 20:19 [RFC PATCH] net: rtnetlink: remove local list in __linkwatch_run_queue() Johannes Berg
2023-12-05 11:22 ` Jiri Pirko
2023-12-05 11:24   ` Johannes Berg

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.