Re: [PATCH] rtase: Avoid sleeping in get_stats64()

[Alexander Lobakin]

From: David Laight <david.laight.linux@xxxxxxxxx>
Date: Wed, 3 Jun 2026 10:59:29 +0100

> On Tue, 2 Jun 2026 15:43:04 +0200
> Alexander Lobakin <aleksander.lobakin@xxxxxxxxx> wrote:
> 
>> From: David Laight <david.laight.linux@xxxxxxxxx>
>> Date: Mon, 1 Jun 2026 22:42:03 +0100
>>
>>> On Mon, 1 Jun 2026 15:14:50 +0200
>>> Alexander Lobakin <aleksander.lobakin@xxxxxxxxx> wrote:
>>>   
>>>> From: Justin Lai <justinlai0215@xxxxxxxxxxx>
>>>> 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@xxxxxxxxxxx>    
>>>>
>>>> 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