Re: [RFC] reduce hugetlb_instantiation_mutex usage

'David Gibson'
2006-11-02T02:29:45Z

On Tue, Oct 31, 2006 at 12:48:13PM +0000, Hugh Dickins wrote:
> On Tue, 31 Oct 2006, 'David Gibson' wrote:
> > On Mon, Oct 30, 2006 at 09:15:20PM -0800, Chen, Kenneth W wrote:
> > >
> > > Instead, I'm asking how private mapping protect race between file truncation
> > > and fault? For shared mapping, it is clear to me that we are using lock_page
> > > to protect file truncate with fault. But I don't see that protection with
> > > private mapping in current upstream kernel.
> >
> > Oh, ok. I can't see how it matters in the PRIVATE case, given that
> > truncate() won't, and shouldn't, truncate privately mapped pages.
>
> Bzzt, it does and should (unless we decide to make hugetlbfs pages diverge
> from the standard for ordinary pages in this respect - could do, but that
> would require thought of its own).

Oh, so it does. That's not the semantic I would have guessed for
MAP_PRIVATE.

> If you've been thinking otherwise,
> that may explain why some of the accounting goes wrong.

Unlikely, given that there basically isn't any accounting for
MAP_PRIVATE pages.

--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!