Messages in this thread | | | Date | Mon, 23 Aug 2010 18:24:49 +0900 | From | Naoya Horiguchi <> | Subject | Re: [PATCH 1/9] HWPOISON, hugetlb: move PG_HWPoison bit check |
| |
On Thu, Aug 19, 2010 at 05:28:28PM +0800, Wu Fengguang wrote: > On Thu, Aug 19, 2010 at 03:55:43PM +0800, Naoya Horiguchi wrote: > > 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. > > That's good stuff to put in the changelog.
OK.
> > 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. > > So you'll remove the first two chunks and retain the 3rd chunk?
Yes.
> That makes it a small bug-fix patch suitable for 2.6.36 and I'll > happily ACK it :)
Thank you!
Naoya Horiguchi
| |