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

[David Laight <david.laight.linux@gmail.com>]

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
>