> > --- a/mm/memory-failure.c
> > +++ b/mm/memory-failure.c
> > @@ -1168,6 +1168,16 @@ int memory_failure(unsigned long pfn, int trapno,
> > int flags)
> > lock_page(hpage);
> >
> > /*
> > +* The page could have changed compound pages during the locking.
> > +* If this happens ju
On Mon, 30 Jun 2014 17:32:16 -0700 Andi Kleen wrote:
> From: Andi Kleen
>
> When a hwpoison page is locked it could change state
> due to parallel modifications. Check after the lock
> if the page is still the same compound page.
>
> ...
>
> --- a/mm/memory-failure.c
> +++ b/mm/memory-failure
> Acked-by: Naoya Horiguchi
>
> Is it -stable matter?
> Maybe 2.6.38+ can profit from this.
Probably not, it's not a critical bug fix.
-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at h
On Mon, Jun 30, 2014 at 05:32:16PM -0700, Andi Kleen wrote:
> From: Andi Kleen
>
> When a hwpoison page is locked it could change state
> due to parallel modifications. Check after the lock
> if the page is still the same compound page.
>
> [v2: Removed earlier non LRU check which should be alr
From: Andi Kleen
When a hwpoison page is locked it could change state
due to parallel modifications. Check after the lock
if the page is still the same compound page.
[v2: Removed earlier non LRU check which should be already
covered elsewhere]
Cc: Naoya Horiguchi
Signed-off-by: Andi Kleen
-
5 matches
Mail list logo