Messages in this thread Patch in this message | | | Date | Thu, 10 Jun 2021 16:50:59 -0700 | From | Andrew Morton <> | Subject | Re: [PATCH v3] mm/hwpoison: do not lock page again when me_huge_page() successfully recovers |
| |
On Wed, 9 Jun 2021 16:20:29 +0900 Naoya Horiguchi <nao.horiguchi@gmail.com> wrote:
> Currently me_huge_page() temporary unlocks page to perform some actions > then locks it again later. My testcase (which calls hard-offline on > some tail page in a hugetlb, then accesses the address of the hugetlb > range) showed that page allocation code detects this page lock on buddy > page and printed out "BUG: Bad page state" message. > > check_new_page_bad() does not consider a page with __PG_HWPOISON as bad > page, so this flag works as kind of filter, but this filtering doesn't > work in this case because the "bad page" is not the actual hwpoisoned > page. So stop locking page again. Actions to be taken depend on the > page type of the error, so page unlocking should be done in ->action() > callbacks. So let's make it assumed and change all existing callbacks > that way.
I'm getting a reject against Linus mainline here, and a -stable patch doesn't want such things happening.
--- mm/memory-failure.c +++ mm/memory-failure.c @@ -1782,6 +1796,8 @@ int memory_failure(unsigned long pfn, int flags) identify_page_state: res = identify_page_state(pfn, p, page_flags); + mutex_unlock(&mf_mutex); + return res; unlock_page: unlock_page(p); unlock_mutex: and... That mutex_unlock() looks odd. The patch adds no matching mutex_lock?
| |