On Wed, Aug 18, 2010 at 08:18:42AM +0800, Wu Fengguang wrote: > On Tue, Aug 10, 2010 at 05:27:36PM +0800, Naoya Horiguchi wrote: > > In order to handle metadatum correctly, we should check whether the hugepage > > we are going to access is HWPOISONed *before* incrementing mapcount, > > adding the hugepage into pagecache or constructing anon_vma. > > This patch also adds retry code when there is a race between > > alloc_huge_page() and memory failure. > > This duplicates the PageHWPoison() test into 3 places without really > address any problem. For example, there are still _unavoidable_ races > between PageHWPoison() and add_to_page_cache(). > > What's the problem you are trying to resolve here? If there are > data structure corruption, we may need to do it in some other ways. The problem I tried to resolve in this patch is the corruption of data structures when memory failure occurs between alloc_huge_page() and lock_page(). The corruption occurs because page fault can fail with metadata changes remained (such as refcount, mapcount, etc.) Since the PageHWPoison() check is for avoiding hwpoisoned page remained in pagecache mapping to the process, it should be done in "found in pagecache" branch, not in the common path. This patch moves the check to "found in pagecache" branch. In addition to that, I added 2 PageHWPoison checks in "new allocation" branches to enhance the possiblity to recover from memory failures on pages under allocation. But it's a different point from the original one, so I drop these retry checks. Thanks, Naoya Horiguchi -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>