[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZFs3RYgdCeKjxYCw@moria.home.lan>
Date: Wed, 10 May 2023 02:18:45 -0400
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: Jan Kara <jack@...e.cz>
Cc: linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-bcachefs@...r.kernel.org,
Kent Overstreet <kent.overstreet@...il.com>,
"Darrick J . Wong" <djwong@...nel.org>, dhowells@...hat.com
Subject: Re: [PATCH 06/32] sched: Add task_struct->faults_disabled_mapping
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@...il.com>
> >
> > 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
> 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.
David Howells was also just running into a strange locking situation with
iov_iters and recursive gups - I don't recall all the details, but it
sounded like this might be a solution for that. David, did you have
thoughts on that?
Powered by blists - more mailing lists