On Wed 10-05-23 02:18:45, Kent Overstreet wrote: > On Wed, May 10, 2023 at 03:07:37AM +0200, Jan Kara wrote: > > On Tue 09-05-23 12:56:31, Kent Overstreet wrote: > > > From: Kent Overstreet <kent.overstreet@xxxxxxxxx> > > > > > > This is used by bcachefs to fix a page cache coherency issue with > > > O_DIRECT writes. > > > > > > Also relevant: mapping->invalidate_lock, see below. > > > > > > O_DIRECT writes (and other filesystem operations that modify file data > > > while bypassing the page cache) need to shoot down ranges of the page > > > cache - and additionally, need locking to prevent those pages from > > > pulled back in. > > > > > > But O_DIRECT writes invoke the page fault handler (via get_user_pages), > > > and the page fault handler will need to take that same lock - this is a > > > classic recursive deadlock if userspace has mmaped the file they're DIO > > > writing to and uses those pages for the buffer to write from, and it's a > > > lock ordering deadlock in general. > > > > > > Thus we need a way to signal from the dio code to the page fault handler > > > when we already are holding the pagecache add lock on an address space - > > > this patch just adds a member to task_struct for this purpose. For now > > > only bcachefs is implementing this locking, though it may be moved out > > > of bcachefs and made available to other filesystems in the future. > > > > It would be nice to have at least a link to the code that's actually using > > the field you are adding. > > Bit of a trick to link to a _later_ patch in the series from a commit > message, but... > > https://evilpiepirate.org/git/bcachefs.git/tree/fs/bcachefs/fs-io.c#n975 > https://evilpiepirate.org/git/bcachefs.git/tree/fs/bcachefs/fs-io.c#n2454 Thanks and I'm sorry for the delay. > > Also I think we were already through this discussion [1] and we ended up > > agreeing that your scheme actually solves only the AA deadlock but a > > malicious userspace can easily create AB BA deadlock by running direct IO > > to file A using mapped file B as a buffer *and* direct IO to file B using > > mapped file A as a buffer. > > No, that's definitely handled (and you can see it in the code I linked), > and I wrote a torture test for fstests as well. I've checked the code and AFAICT it is all indeed handled. BTW, I've now remembered that GFS2 has dealt with the same deadlocks - b01b2d72da25 ("gfs2: Fix mmap + page fault deadlocks for direct I/O") - in a different way (by prefaulting pages from the iter before grabbing the problematic lock and then disabling page faults for the iomap_dio_rw() call). I guess we should somehow unify these schemes so that we don't have two mechanisms for avoiding exactly the same deadlock. Adding GFS2 guys to CC. Also good that you've written a fstest for this, that is definitely a useful addition, although I suspect GFS2 guys added a test for this not so long ago when testing their stuff. Maybe they have a pointer handy? Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
