RE: [RFC] reduce hugetlb_instantiation_mutex usage

Chen, Kenneth W
2006-10-31T02:54:46Z

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?

- Ken