On Tue, Oct 15, 2024 at 10:06:52AM GMT, Joanne Koong wrote: > On Tue, Oct 15, 2024 at 3:01 AM Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > > > On Mon, 14 Oct 2024 at 20:23, Joanne Koong <joannelkoong@xxxxxxxxx> wrote: > > > > > This change sets AS_NO_WRITEBACK_RECLAIM on the inode mapping so that > > > FUSE folios are not reclaimed and waited on while in writeback, and > > > removes the temporary folio + extra copying and the internal rb tree. > > > > What about sync(2)? And page migration? > > > > Hopefully there are no other cases, but I think a careful review of > > places where generic code waits for writeback is needed before we can > > say for sure. > > Sounds good, that's a great point. I'll audit the other places in the > mm code where we might call folio_wait_writeback() and report back > what I find. > > So, any operation that the fuse server can do which can cause wait on writeback on the folios backed by the fuse is problematic. We know about one scenario i.e. memory allocation causing reclaim which may do the wait on unrelated folios which may be backed by the fuse server. Now there are ways fuse server can shoot itself on the foot. Like sync() syscall or accessing the folios backed by itself. The quesion is should we really need to protect fuse from such cases?
