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

[Cen Zhang]

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:

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

Thanks,
Cen