On Thu, Dec 13, 2018 at 03:56:05PM +0000, Christopher Lameter wrote: > On Wed, 12 Dec 2018, Jerome Glisse wrote: > > > On Thu, Dec 13, 2018 at 11:51:19AM +1100, Dave Chinner wrote: > > > > > > [O1] Avoid write back from a page still being written by either a > > > > > > device or some direct I/O or any other existing user of GUP. > > > > > > IOWs, you need to mark pages being written to by a GUP as > > > PageWriteback, so all attempts to write the page will block on > > > wait_on_page_writeback() before trying to write the dirty page. > > > > No you don't and you can't for the simple reasons is that the GUP > > of some device driver can last days, weeks, months, years ... so > > it is not something you want to do. Here is what happens today: > > I think it would be better to use the established way to block access that > Dave suggests. Maybe deal with the issue of threads being blocked for > a long time instead? Introduce a way to abort these attempts in a > controlled fashion that also allows easy debugging of these conflicts? GUP does not have the information on how long the GUP will last, the GUP caller might not know either. What is worse is that the GUP user provide API today to userspace to do this and thus any attempt to block this from happening can be interpreted (from some point of view) as a regression ie worked in linux X.Y does not work in linux X.Y+1. I am not against doing that, in fact i advocated at last LSF that any user of GUP that does not abide to mmu notifier should be denied GUP (direct IO, kvm and couple other like that being the exception because they are case we can properly fix). Anyone that abide to mmu notifier will drop the page reference on any event like truncate, split, mremap, munmap, write back ... so anyone with mmu notifier is fine. Cheers, Jérôme
