Re: RFC: reviving mlock isolation dead code

[Michel Lespinasse <walken@google.com>]

On Mon, Nov 15, 2010 at 5:44 PM, Hugh Dickins <hughd@google.com> wrote:
> On Sun, 14 Nov 2010, KOSAKI Motohiro wrote:
>> Michel Lespinasse <walken@google.com> wrote:
>> > ...
>> > The other mlock related issue I have is that it marks pages as dirty
>> > (if they are in a writable VMA), and causes writeback to work on them,
>> > even though the pages have not actually been modified. This looks like
>> > it would be solvable with a new get_user_pages flag for mlock use
>> > (breaking cow etc, but not writing to the pages just yet).
>>
>> To be honest, I haven't understand why current code does so. I dislike it too. but
>> I'm not sure such change is safe or not. I hope another developer comment you ;-)
>
> It's been that way for years, and the primary purpose is to do the COWs
> in advance, so we won't need to allocate new pages later to the locked
> area: the pages that may be needed are already locked down.

Thanks Hugh for posting your comments. I was aware of Suleiman's
proposal to always do a READ mode get_user_pages years ago, and I
could see that we'd need a new flag instead so we can break COW
without dirtying pages, but I hadn't thought about other issues.

> That justifies it for the private mapping case, but what of shared maps?
> There the justification is that the underlying file might be sparse, and
> we want to allocate blocks upfront for the locked area.
>
> Do we?  I dislike it also, as you both do.  It seems crazy to mark a
> vast number of pages as dirty when they're not.
>
> It makes sense to mark pte_dirty when we have a real write fault to a
> page, to save the mmu from making that pagetable transaction immediately
> after; but it does not make sense when the write (if any) may come
> minutes later - we'll just do a pointless write and clear dirty meanwhile