Re: [PATCH] tty: n_tty: order lockless input availability checks

[Greg KH]

On Mon, May 04, 2026 at 03:47:01PM +0800, Cen Zhang wrote:
> Dear Greg KH
> 
> Thanks for taking a look, and sorry if the changelog made this sound
> stronger than the evidence I have.
> 
> > What tests show that this is needed?  That commit was a long time ago,
> > and surely we would have had some bug reports since then, right?
> >
> > thanks,
> >
> > greg k-h
> 
> The evidence I have is from data-race reports produced while stressing
> pty/tty ioctls.  The relevant stacks, mapped to current v7.0.3 source,
> are:

Cool, where are those reports?

>   - read/unthrottle side:
>       chars_in_buffer() at drivers/tty/n_tty.c:216
>       n_tty_check_unthrottle() at drivers/tty/n_tty.c:275
>       n_tty_read()
> 
>     racing with the receive side:
>       n_tty_receive_char_canon() at drivers/tty/n_tty.c:1258
>       __receive_buf() at drivers/tty/n_tty.c:1588
> 
>   - poll/select side:
>       input_available_p() at drivers/tty/n_tty.c:1912-1915
>       n_tty_poll() at drivers/tty/n_tty.c:2440/2444
> 
>     racing with termios changes:
>       n_tty_set_termios() at drivers/tty/n_tty.c:1782,
>       drivers/tty/n_tty.c:1786 and drivers/tty/n_tty.c:1789
> 
> My reasoning was that these helpers sample the same lockless read-buffer
> availability state that the read/copy paths already handle with
> smp_store_release()/smp_load_acquire(), but I do not have a test showing
> a concrete functional failure beyond the data-race reports.
> 
> Would you prefer that I drop the Fixes tag and respin the changelog to
> describe this as a conservative KCSAN/LKMM cleanup?  Or do you think the
> evidence is too weak for a change here?

I don't really know as I haven't seen any such reports before that I can
recall.

thanks,

greg k-h