[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <SJ1PR11MB608319A906F5DB0AB18C1913FC482@SJ1PR11MB6083.namprd11.prod.outlook.com>
Date: Mon, 12 Feb 2024 21:18:51 +0000
From: "Luck, Tony" <tony.luck@...el.com>
To: "paulmck@...nel.org" <paulmck@...nel.org>, Borislav Petkov <bp@...en8.de>
CC: Yazen Ghannam <yazen.ghannam@....com>, "Naik, Avadhut" <avadnaik@....com>,
"Mehta, Sohil" <sohil.mehta@...el.com>, "x86@...nel.org" <x86@...nel.org>,
"linux-edac@...r.kernel.org" <linux-edac@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Avadhut Naik
<avadhut.naik@....com>
Subject: RE: [PATCH 2/2] x86/MCE: Add command line option to extend MCE
Records pool
>> and this is exactly what we're doing - adding new memory.
>
> Is the #MC adding new memory, or is the interrupted context adding new
> memory?
The interrupted context is adding the memory.
>> So, until we're absolutely sure that it is ok to interrupt a context
>> holding a spinlock with a #MC which is non-maskable, I don't think we
>> wanna do this.
>
> If it is the #MC adding new memory, agreed.
Not what is happening.
> If the #MC is simply traversing the list, and the interrupted context
> was in the midst of adding a new element, this should be no worse than
> some other CPU traversing the list while this CPU is in the midst of
> adding a new element.
>
> Or am I missing a turn in here somewhere?
Not missing anything. I believe you've answered the question.
-Tony
Powered by blists - more mailing lists