[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4de52973-7590-8ba8-62ca-c78e42f36a63@huawei.com>
Date: Sat, 29 Oct 2022 09:55:23 +0800
From: Miaohe Lin <linmiaohe@...wei.com>
To: "Luck, Tony" <tony.luck@...el.com>
CC: Matthew Wilcox <willy@...radead.org>,
Shuai Xue <xueshuai@...ux.alibaba.com>,
"Williams, Dan J" <dan.j.williams@...el.com>,
Michael Ellerman <mpe@...erman.id.au>,
Nicholas Piggin <npiggin@...il.com>,
Christophe Leroy <christophe.leroy@...roup.eu>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
Naoya Horiguchi <naoya.horiguchi@....com>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH v3 2/2] mm, hwpoison: When copy-on-write hits poison, take
page offline
On 2022/10/29 0:13, Luck, Tony wrote:
>>> Cannot call memory_failure() directly from the fault handler because
>>> mmap_lock (and others) are held.
>>
>> Could you please explain which lock makes it unfeasible to call memory_failure() directly and
>> why? I'm somewhat confused. But I agree using memory_failure_queue() should be a good idea.
>
> I tried calling memory_failure() directly, and my system just hung. I made the assumption
> that it had deadlocked based somewhat on the comments in mm/memory.c about mmap_lock
> being held ... but I didn't dig into what had gone wrong.
I see. Thanks for your explanation. :)
>
> -Tony
>
Powered by blists - more mailing lists