On Fri 18-11-11 17:11:28, Michal Hocko wrote:

On Fri 18-11-11 23:23:12, Hillf Danton wrote:

quoted

On Fri, Nov 18, 2011 at 11:07 PM, Michal Hocko [off-list ref] wrote:

quoted

On Fri 18-11-11 22:04:37, Hillf Danton wrote:

quoted

In the error path that we fail to allocate new huge page, before try again, we
have to check race since page_table_lock is re-acquired.

I do not think we can race here because we are serialized by
hugetlb_instantiation_mutex AFAIU. Without this lock, however, we could
fall into avoidcopy and shortcut despite the fact that other thread has
already did the job.

The mutex usage is not obvious in hugetlb_cow so maybe we want to be
explicit about it (either a comment or do the recheck).

Then the following check is unnecessary, no?

Hmm, thinking about it some more, I guess we have to recheck because we
can still race with page migration. So we need you patch.

OK, so looked at it again and we cannot race with page migration because
the page is locked (by unmap_and_move_*page) migration and we have the
old page locked here as well (hugetlb_fault).

Or am I missing something?

-- 
Michal Hocko
SUSE Labs
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9    
Czech Republic

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>