On Thu, May 23, 2024 at 12:59 AM Bernd Schubert <bernd.schubert@xxxxxxxxxxx> wrote: > > Amir, Miklos, > > I'm preparing fuse-over-io-uring RFC2 and running xfstests on > 6.9. First run is without io-uring (patches applied, though) and > generic/095 reports a circular lock dependency. > > (I probably should disable passthrough in my uring patches > or add an iteration without it). > > iter_file_splice_write > pipe_lock(pipe) --> pipe first > ... > call_write_iter / fuse_file_write_iter > fuse_file_write_iter > fuse_direct_write_iter > fuse_dio_lock > inode_lock_shared --> then inode lock > > > and > > do_splice > fuse_passthrough_splice_write --> inode lock first > backing_file_splice_write > iter_file_splice_write > pipe_lock(pipe); --> then pipe lock > > Not sure, but this looks like the reason that ovl_splice_write() was added (see comment above it). I think that fuse_passthrough_splice_write() and fuse_passthrough_write_iter() are probably deadlock safe against each other, so I guess we could teach lockdep that passthrough inodes are a different class than non-passthrough inodes, but I think that is not easy to change mid inode lifetime. Also, I think that mixed passthrough/dio mode may be breaking this order for a given inode - I cannot wrap my head around it. Will need Miklos here. Question: mmap+dio does not make sense so we let passthrough overrule dio for mmap in mixed mode. Does splice+dio make sense? or can we also force passthrough splice when inode has a backing file? Another thing that we will need to do is annotate different lockdep class for nested fuse passthrough as we did in ovl_lockdep_annotate_inode_mutex_key(). Lots of fun... Thanks, Amir.
