[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <SJ1PR11MB608354A1D8817902D7FC9DFAFC329@SJ1PR11MB6083.namprd11.prod.outlook.com>
Date: Fri, 28 Oct 2022 16:13:08 +0000
From: "Luck, Tony" <tony.luck@...el.com>
To: Miaohe Lin <linmiaohe@...wei.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
>> 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.
-Tony
Powered by blists - more mailing lists