Thread (36 messages) 36 messages, 5 authors, 2003-02-05

Re: hugepage patches

From: Andrew Morton <hidden>
Date: 2003-02-05 19:57:59

ebiederm@xmission.com (Eric W. Biederman) wrote:
Andrew Morton [off-list ref] writes:
quoted
ebiederm@xmission.com (Eric W. Biederman) wrote:
quoted
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/
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help