On Fri, Aug 08, 2025 at 09:43:10PM +0800, Alan Huang wrote: > This provides our own splice read, which locks ei_pagecache_lock around > filemap_splice_read. > > Signed-off-by: Alan Huang <[email protected]> > --- > fs/bcachefs/fs-io-buffered.c | 12 ++++++++++++ > fs/bcachefs/fs-io-buffered.h | 4 ++++ > 2 files changed, 16 insertions(+) > > diff --git a/fs/bcachefs/fs-io-buffered.c b/fs/bcachefs/fs-io-buffered.c > index fd8beb5167ee..c16c45a72c47 100644 > --- a/fs/bcachefs/fs-io-buffered.c > +++ b/fs/bcachefs/fs-io-buffered.c > @@ -1100,6 +1100,18 @@ ssize_t bch2_write_iter(struct kiocb *iocb, struct > iov_iter *from) > return bch2_err_class(ret); > } > > +ssize_t bch2_splice_read(struct file *in, loff_t *ppos, > + struct pipe_inode_info *pipe, > + size_t len, unsigned int flags) > +{ > + ssize_t ret; > + struct bch_inode_info *inode = to_bch_ei(in->f_mapping->host); > + bch2_pagecache_add_get(inode); > + ret = filemap_splice_read(in, ppos, pipe, len, flags); > + bch2_pagecache_add_put(inode); > + return ret; > +}
Taking the lock here, around the entire splice_read() call sucks - most buffered reads (and this is the fastpath, which we care about) will be reading from cache, i.e. they aren't adding new folios to the pagecache and they don't need pagecache_add lock. Meaning, we really don't want to add two new atomic ops on the inode to every buffered read. Does this help with lockdep at all? The main issue is still the fault path vs. mmap_lock.
