Re: [PATCH v2] 9p: fix i_size update race in getattr with writeback caching

[David Howells]

David Howells <dhowells@xxxxxxxxxx> wrote:

> > [   60.847671] [append] R=134d: No submit
> 
> Can you get me some tracing?  If you can turn on:

Nevermind, I've managed to reproduce it - but only with the virtio transport
and not the tcp one.  It also doesn't seem to show anything with afs.

     9p_repro.sh-1399 : netfs_folio: i=d306b44 ix=00000-00000 mod-streamw
     9p_repro.sh-1401 : netfs_folio: i=d306b44 ix=00000-00000 flush
     9p_repro.sh-1401 : netfs_write: R=000001be WRITEBACK c=00000000 i=d306b44 by=0-ffffffffffffffff
     9p_repro.sh-1401 : netfs_folio: i=d306b44 ix=00000-00000 store
   kworker/u32:2-63   : netfs_rreq: R=000001be WB COLLECT f=903
   kworker/u32:2-63   : netfs_rreq: R=000001be WB WR-DONE f=903
   kworker/u32:2-63   : netfs_rreq: R=000001be WB WAKE-IP f=902
   kworker/u32:2-63   : netfs_rreq: R=000001be WB FREE    f=902

Looks like netfs failed to flush an incompatible streaming write.  The folio
was moved to the 'store' state, but no subrequests were generated for some
reason.

*Why* it produced an incompatible streaming write is an interesting question.
The writes are all done with O_APPEND, so even if the processes write out of
order, there shouldn't be a problem...

David