Re: [patch 3/8] mm: merge nopfn into fault

Benjamin Herrenschmidt
2007-05-23T23:40:19Z

On Fri, 2007-05-18 at 08:23 -0700, Linus Torvalds wrote:
>
> If we are changing the calling semantics of "nopage", then we should also
> remove the horrible, horrible hack of making the "nopfn" function itself
> do the "populate the page tables".
>
> It would be *much* better to just

.../...

> and let the caller always insert the thing into the page tables.
>
> Wouldn't it be nice if we never had drivers etc modifying page tables
> directly? Even with helpers like "vm_insert_pfn()"?

The problem is that this is racy vs. concurrent unmap_mapping_range().

As I explained in my previous email, spufs and the DRI are 2 examples
where we need to expose to userland a mapping whose backing PFN's have
to be switched between different physical storage.

The only way I've found to have this be race free is to have the
->nopfn() function do the actual PTE insertion while holding a
lock/mutex that is also taken by whatever calles unmap_mapping_range()
when the switching occurs).

Cheers,
Ben.