On Wed, 25 May 2022, cael wrote: > >Now you switched to an entirely different case, not the one we were > >talking about. ...There is no ldisc->no_room = true race in the case > >you now described. > So, I think we should back to the case ldata->no_room=true as > ldata->no_room=false seems harmless. > > >I'm not worried about the case where both cpus call n_tty_kick_worker but > >the case where producer cpu sees chars_in_buffer() > 0 and consumer cpu > >!no_room. > > As ldata->no_room=true is set before checking chars_in_buffer() Please take a brief look at Documentation/memory-barriers.txt and then tell me if you still find this claim to be true. > if producer > finds chars_in_buffer() > 0, then if reader is currently in n_tty_read, ...Then please do a similar analysis for ldata->read_tail. What guarantees its update is seen by the producer cpu when the reader is already past the point you think it still must be in? > when reader quits n_tty_read, n_tty_kick_worker will be called. If reader > has already exited n_tty_read, which means that reader still has data to read, > next time reader will call n_tty_kick_worker inside n_tty_read too. C-level analysis alone is not going to be very useful here given you're dealing with a concurrency challenge here. -- i.
