[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20220309133010.0f04c2ac4939edbdb35723bb@linux-foundation.org>
Date: Wed, 9 Mar 2022 13:30:10 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: Naoya Horiguchi <naoya.horiguchi@...ux.dev>
Cc: linux-mm@...ck.org, Mike Kravetz <mike.kravetz@...cle.com>,
Miaohe Lin <linmiaohe@...wei.com>,
Yang Shi <shy828301@...il.com>,
Naoya Horiguchi <naoya.horiguchi@....com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1] mm/hwpoison: set PageHWPoison after taking page lock
in memory_failure_hugetlb()
On Wed, 9 Mar 2022 18:14:49 +0900 Naoya Horiguchi <naoya.horiguchi@...ux.dev> wrote:
> There is a race condition between memory_failure_hugetlb() and hugetlb
> free/demotion, which causes setting PageHWPoison flag on the wrong page
> (which was a hugetlb when memory_failrue() was called, but was removed
> or demoted when memory_failure_hugetlb() is called). This results in
> killing wrong processes. So set PageHWPoison flag with holding page lock,
What are the runtime effects of this? Do we think a -stable backport
is needed?
Are we missing a reported-by here? I'm too lazy to hunt down who it was.
Powered by blists - more mailing lists