On Sat, Oct 29, 2022 at 01:15:26PM -0700, Linus Torvalds wrote: > On Sat, Oct 29, 2022 at 12:39 PM John Hubbard <jhubbard@xxxxxxxxxx> wrote: > > > > ext4 has since papered over the problem, by soldiering on if it finds a > > page without writeback buffers when it expected to be able to writeback > > a dirty page. But you get the idea. > > I suspect that "soldiering on" is the right thing to do, but yes, our > 'mkdirty' vs 'mkclean' thing has always been problematic. > > ... > > (a) filesystems just deal with it It should be noted that "soldiering on" just means that the kernel will not crash or BUG. It may mean that the dirty page will not gotten written back (since at the time when it is discovered we are in a context we may not allocate memory or block if there is a need to allocate blocks if the file system uses delayed allocation). Furthermore, since the file system does not know that one or more pages have dirtied behind it's back, if the file system is almost full, some writes may silently fail --- including writes where the usesrspace application was implicitly promised that the write would succeed by having the write(2) system call return without errors. If people are OK with that, it's fine. Just don't complain to the file system maintainers. :-) - Ted P.S. The reason why this isn't an utter disaster is because normally users of remote RMA use preallocated and pre-written/initialized files. And there aren't _that_ many other users of gup. So long as this remains the case, we might be happy to let sleeping canines lie. Just please dear $DEITY, let's not have any additional users of gup until we have a better solution.
