[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: hugepage patches



ebiederm@xmission.com (Eric W. Biederman) wrote:
>
> Andrew Morton <akpm@digeo.com> writes:
> 
> > ebiederm@xmission.com (Eric W. Biederman) wrote:
> > >
> > > I can't imagine it being useful to guys like oracle without MAP_SHARED
> > > support....
> > 
> > MAP_SHARED is supported.  I haven't tested it much though.
> 
> Given that none of the standard kernel idioms to prevent races in
> this kind of code are present, I would be very surprised if it
> was not racy.
> 
> - inode->i_sem is not taken to protect inode->i_size.

OK, I'll fix that up.

> - After successfully allocating a page, a test is not made to see if
>   another process with the same mapping has allocated the page first.

In this case, add_to_page_cache() in hugetlb_prefault() will return -EEXIST,
and the page which lost the race will be freed again.

Uh, but we don't establish a pte against the page which got there first. 
I'll fix that up too.  Thanks.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/