<div dir="auto"><div>Sorry, I'm on a boat right now, with only a cellphone. Which is why this html mess email, and quick reply.</div><div dir="auto"><br></div><div dir="auto">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.<br><div dir="auto"><br></div><div dir="auto">I'll be out most of the day, but I'll try to take a deeper look this evening.</div><br>I'm the meantime, a couple of questions and comments..</div><div dir="auto"><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Mon, May 31, 2021, 07:01 Andreas Gruenbacher <<a href="mailto:agruenba@redhat.com">agruenba@redhat.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
here's a set of fixes for how gfs2 handles page faults during read and<br>
write syscalls.</blockquote></div></div><div dir="auto"><br></div><div dir="auto">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?</div><div dir="auto"><br></div><div dir="auto">See my reply to that pull request for why it's wrong and pointless.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">  The patch queue is ready for merging except for two<br>
open issues.  <br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">      Linus</div><div dir="auto"><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>