On 5/25/24 17:40, Amir Goldstein wrote: > 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... I'm just in the middle of other code - I don't want to get distracted too much right now, will look at it in more detail later. My test had totally locked up up - lock annotation is not enough here. >From the traces and from the test this is mixed dio/page cache IO - I think that is the same test that had found issues with mmap and FOPEN_DIRECT_IO in winter. Thanks, Bernd
