[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/