Netdev List
 help / color / mirror / Atom feed
* [PATCH] rtase: Avoid sleeping in get_stats64()
@ 2026-06-01  6:24 Justin Lai
  2026-06-01 13:14 ` Alexander Lobakin
  0 siblings, 1 reply; 3+ messages in thread
From: Justin Lai @ 2026-06-01  6:24 UTC (permalink / raw)
  To: kuba
  Cc: davem, edumazet, pabeni, andrew+netdev, linux-kernel, netdev,
	horms, pkshih, larry.chiu, Justin Lai

The .ndo_get_stats64 callback must not sleep because it can be
called when reading /proc/net/dev.

rtase_get_stats64() calls rtase_dump_tally_counter(), which polls
the tally counter dump bit with read_poll_timeout(). This may
sleep while waiting for the hardware counter dump to complete.

Use read_poll_timeout_atomic() instead to avoid sleeping in the
get_stats64() path.

Signed-off-by: Justin Lai <justinlai0215@realtek.com>
---
 drivers/net/ethernet/realtek/rtase/rtase_main.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/realtek/rtase/rtase_main.c b/drivers/net/ethernet/realtek/rtase/rtase_main.c
index 11e9d0feea68..17912f372740 100644
--- a/drivers/net/ethernet/realtek/rtase/rtase_main.c
+++ b/drivers/net/ethernet/realtek/rtase/rtase_main.c
@@ -1618,8 +1618,9 @@ static void rtase_dump_tally_counter(const struct rtase_private *tp)
 	rtase_w32(tp, RTASE_DTCCR0, cmd);
 	rtase_w32(tp, RTASE_DTCCR0, cmd | RTASE_COUNTER_DUMP);
 
-	err = read_poll_timeout(rtase_r32, val, !(val & RTASE_COUNTER_DUMP),
-				10, 250, false, tp, RTASE_DTCCR0);
+	err = read_poll_timeout_atomic(rtase_r32, val,
+				       !(val & RTASE_COUNTER_DUMP),
+				       10, 250, false, tp, RTASE_DTCCR0);
 
 	if (err == -ETIMEDOUT)
 		netdev_err(tp->dev, "error occurred in dump tally counter\n");
-- 
2.40.1


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

* Re: [PATCH] rtase: Avoid sleeping in get_stats64()
  2026-06-01  6:24 [PATCH] rtase: Avoid sleeping in get_stats64() Justin Lai
@ 2026-06-01 13:14 ` Alexander Lobakin
  2026-06-01 21:42   ` David Laight
  0 siblings, 1 reply; 3+ messages in thread
From: Alexander Lobakin @ 2026-06-01 13:14 UTC (permalink / raw)
  To: Justin Lai
  Cc: kuba, davem, edumazet, pabeni, andrew+netdev, linux-kernel,
	netdev, horms, pkshih, larry.chiu

From: Justin Lai <justinlai0215@realtek.com>
Date: Mon, 1 Jun 2026 14:24:47 +0800

> The .ndo_get_stats64 callback must not sleep because it can be
> called when reading /proc/net/dev.
> 
> rtase_get_stats64() calls rtase_dump_tally_counter(), which polls
> the tally counter dump bit with read_poll_timeout(). This may
> sleep while waiting for the hardware counter dump to complete.
> 
> Use read_poll_timeout_atomic() instead to avoid sleeping in the
> get_stats64() path.
> 
> Signed-off-by: Justin Lai <justinlai0215@realtek.com>

Looks legit.

One question: for how long can this poll for in real life scenarios? Up
to ~1 ms is okay-ish for atomic, but if longer, then you'd better to
split it into shorter polls and reschedule() time to time.

Thanks,
Olek

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

* Re: [PATCH] rtase: Avoid sleeping in get_stats64()
  2026-06-01 13:14 ` Alexander Lobakin
@ 2026-06-01 21:42   ` David Laight
  0 siblings, 0 replies; 3+ messages in thread
From: David Laight @ 2026-06-01 21:42 UTC (permalink / raw)
  To: Alexander Lobakin
  Cc: Justin Lai, kuba, davem, edumazet, pabeni, andrew+netdev,
	linux-kernel, netdev, horms, pkshih, larry.chiu

On Mon, 1 Jun 2026 15:14:50 +0200
Alexander Lobakin <aleksander.lobakin@intel.com> wrote:

> From: Justin Lai <justinlai0215@realtek.com>
> Date: Mon, 1 Jun 2026 14:24:47 +0800
> 
> > The .ndo_get_stats64 callback must not sleep because it can be
> > called when reading /proc/net/dev.
> > 
> > rtase_get_stats64() calls rtase_dump_tally_counter(), which polls
> > the tally counter dump bit with read_poll_timeout(). This may
> > sleep while waiting for the hardware counter dump to complete.
> > 
> > Use read_poll_timeout_atomic() instead to avoid sleeping in the
> > get_stats64() path.
> > 
> > Signed-off-by: Justin Lai <justinlai0215@realtek.com>  
> 
> Looks legit.
> 
> One question: for how long can this poll for in real life scenarios? Up
> to ~1 ms is okay-ish for atomic, but if longer, then you'd better to
> split it into shorter polls and reschedule() time to time.

Anyone trying to get a thread running at an RT priority won't thank you
for spinning for anywhere near that long.
When an RT processes becomes runnable the scheduler will preempt a lower
priority process that is running on the cpu the RT process last ran on.
The RT process won't run until the preempt actually happens.

1ms is a very long time.

-- David

> 
> Thanks,
> Olek
> 


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

end of thread, other threads:[~2026-06-01 21:42 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-06-01  6:24 [PATCH] rtase: Avoid sleeping in get_stats64() Justin Lai
2026-06-01 13:14 ` Alexander Lobakin
2026-06-01 21:42   ` David Laight

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox