Re: [RFC] reduce hugetlb_instantiation_mutex usage

'David Gibson'
2006-10-31T03:17:04Z

On Mon, Oct 30, 2006 at 06:54:46PM -0800, Chen, Kenneth W wrote:
> David Gibson wrote on Thursday, October 26, 2006 9:06 PM
> > > Alternatively, we could put the page into pagecache whether or not the
> > > mapping is MAP_SHARED. Then pull it out again prior to unlocking it if
> > > it's MAP_PRIVATE. So we're using pagecache just as a way for the
> > > concurrent faulter to locate the page.
> >
> > Hrm.. interesting if we can make it work. I'd be worried about cases
> > with concurrent PRIVATE and SHARED pages on the same file offset.
>
> I got side tracked on to the radix-tree stuff. The comments in
> hugetlb_no_page() make me wonder whether we have a race issue on
> private mapping:
>
> /*
> * Use page lock to guard against racing truncation
> * before we get page_table_lock.
> */
>
> Private mapping won't use radix tree during instantiation. What protects
> racy truncate against fault in that scenario? Don't we have a bug here?

Not at present, because the hugetlb_instantiation_mutex protects both
fault paths. But with Andrew's patch as it stands, yes. As I said in
a previous email. The libhugetlbfs testsuite now has a testcase for
the MAP_PRIVATE as well as the MAP_SHARED version of the race.

--
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_!