Sorry, I'm on a boat right now, with only a cellphone. Which is why this html mess email, and quick reply.
Due to the html, this may get a bounce from the mailing list, and only make it to the personal email recipients. Feel free to quote more just in case others didn't get my original email through the lists. I'll be out most of the day, but I'll try to take a deeper look this evening. I'm the meantime, a couple of questions and comments.. On Mon, May 31, 2021, 07:01 Andreas Gruenbacher <[email protected]> wrote: > > here's a set of fixes for how gfs2 handles page faults during read and > write syscalls. So how much of this is due to the confusion you just introduced where you pointlessly and incorrectly take an exclusive luck for write faults? See my reply to that pull request for why it's wrong and pointless. The patch queue is ready for merging except for two > open issues. > There is no way this series is acceptable for 5.13. This kind of change is very much a merge window thing. Much much too late to make fundamental locking changes. Maybe it can then be backported to stable (including at that point 5.13 of course) if it's been shown to be ok. This deadlock is not new, we've very much had the same kind of thing when writing to a file in the generic filemap_write() function, where we take the page lock and then copy from user space. If that copy faults, and needs the same page for the source due to an odd mmap issue (usually malicious), you get a deadlock on the page lock it you aren't careful. I'm surprised that gfs2 hasn't seen this, I thought we had fstests for it. And I'd have expected that case to also trigger any internal gfs2 issues, although it's possible that the generic code just does such a good job at avoiding the issue that we'd need another test for your case. Linus >
