On Sat 15-04-17 00:59:46, Bart Van Assche wrote: > On Fri, 2017-04-14 at 17:40 -0700, Hugh Dickins wrote: > > Changing a fundamental function, silently not to do its essential job, > > when something in the kernel has forgotten (or is slow to) unlock_page(): > > that seems very wrong to me in many ways. But linux-fsdevel, Cc'ed, will > > be a better forum to advise on how to solve the problem you're seeing. > > Hello Hugh, > > It seems like you have misunderstood the purpose of the patch I posted. It's > neither a missing unlock_page() nor slow I/O that I want to address but a > genuine deadlock. In case you would not be familiar with the queue_if_no_path > multipath configuration option, the multipath.conf man page is available at > e.g. https://linux.die.net/man/5/multipath.conf. So, whole is holding the page lock and why it cannot make forward progress? Is the storage gone so that the ongoing IO will never terminate? Btw. we have many other places which wait for the page lock !killable way. Why they are any different from this case? -- Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
