1. Patchew
  2. linux
  3. View series

[PATCH] rtase: Avoid sleeping in get_stats64()

Justin Lai posted 1 patch 6 days, 23 hours ago
There is a newer version of this series
drivers/net/ethernet/realtek/rtase/rtase_main.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
[PATCH] rtase: Avoid sleeping in get_stats64()
Posted by Justin Lai 6 days, 23 hours ago 
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
Re: [PATCH] rtase: Avoid sleeping in get_stats64()
Posted by Alexander Lobakin 6 days, 16 hours ago 
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
RE: [PATCH] rtase: Avoid sleeping in get_stats64()
Posted by Justin Lai 5 days, 18 hours ago 
> 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

Hi Olek,
 
Thanks for the review.
 
On our test platform, the tally dump operation typically
completes in about 25 us. The 250 us timeout is a
conservative value.
 
I'll add the Fixes tag and resend this patch targeting
the net tree.
 
Thanks,
Justin
Re: [PATCH] rtase: Avoid sleeping in get_stats64()
Posted by Jakub Kicinski 5 days, 11 hours ago 
On Tue, 2 Jun 2026 10:50:13 +0000 Justin Lai wrote:
> I'll add the Fixes tag and resend this patch targeting
> the net tree.

You can just reply with the Fixes tag here, our tooling collects those
from the list, like it does review tags. No need to repost.
RE: [PATCH] rtase: Avoid sleeping in get_stats64()
Posted by Justin Lai 5 days, 1 hour ago 
Jakub Kicinski <kuba@kernel.org> wrote:
> On Tue, 2 Jun 2026 10:50:13 +0000 Justin Lai wrote:
> > I'll add the Fixes tag and resend this patch targeting the net tree.
> 
> You can just reply with the Fixes tag here, our tooling collects those from the
> list, like it does review tags. No need to repost.

Hi Jakub,

Thanks for the suggestion.

This patch was originally based on net-next. I will repost it against
net with a Fixes tag and Cc: stable@vger.kernel.org.

Thanks,
Justin
Re: [PATCH] rtase: Avoid sleeping in get_stats64()
Posted by David Laight 6 days, 7 hours ago 
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
>
Re: [PATCH] rtase: Avoid sleeping in get_stats64()
Posted by Alexander Lobakin 5 days, 15 hours ago 
From: David Laight <david.laight.linux@gmail.com>
Date: Mon, 1 Jun 2026 22:42:03 +0100

> 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.

That's why I wrote "okay-ish". Ideally atomic polling should not go past
100 us, I usually used it for no longer than 10-50 us.

The author says that it usually takes around 25 us which is acceptable
I'd say.

Thanks,
Olek
Re: [PATCH] rtase: Avoid sleeping in get_stats64()
Posted by David Laight 4 days, 19 hours ago 
On Tue, 2 Jun 2026 15:43:04 +0200
Alexander Lobakin <aleksander.lobakin@intel.com> wrote:

> From: David Laight <david.laight.linux@gmail.com>
> Date: Mon, 1 Jun 2026 22:42:03 +0100
> 
> > 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.  
> 
> That's why I wrote "okay-ish". Ideally atomic polling should not go past
> 100 us, I usually used it for no longer than 10-50 us.
> 
> The author says that it usually takes around 25 us which is acceptable
> I'd say.

Just about :-)

Would anyone notice if the read stats code returned slightly old values
and did a async request to get the current ones?

Probably more work for a back-port though.

-- David

> 
> Thanks,
> Olek
>
Re: [PATCH] rtase: Avoid sleeping in get_stats64()
Posted by Alexander Lobakin 4 days, 16 hours ago 
From: David Laight <david.laight.linux@gmail.com>
Date: Wed, 3 Jun 2026 10:59:29 +0100

> On Tue, 2 Jun 2026 15:43:04 +0200
> Alexander Lobakin <aleksander.lobakin@intel.com> wrote:
> 
>> From: David Laight <david.laight.linux@gmail.com>
>> Date: Mon, 1 Jun 2026 22:42:03 +0100
>>
>>> 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.  
>>
>> That's why I wrote "okay-ish". Ideally atomic polling should not go past
>> 100 us, I usually used it for no longer than 10-50 us.
>>
>> The author says that it usually takes around 25 us which is acceptable
>> I'd say.
> 
> Just about :-)
> 
> Would anyone notice if the read stats code returned slightly old values
> and did a async request to get the current ones?

Yep, async would be ideal here.

> 
> Probably more work for a back-port though.
> 
> -- David

Thanks,
Olek

Patchew 2.1-devel-ea86937

© 2016 - 2026 Red Hat, Inc.