[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240212201038.GNZcp7PuIqIJndpDM9@fat_crate.local>
Date: Mon, 12 Feb 2024 21:10:38 +0100
From: Borislav Petkov <bp@...en8.de>
To: "Luck, Tony" <tony.luck@...el.com>
Cc: Yazen Ghannam <yazen.ghannam@....com>,
"Naik, Avadhut" <avadnaik@....com>,
"Paul E . McKenney" <paulmck@...nel.org>,
"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
On Mon, Feb 12, 2024 at 07:49:43PM +0000, Luck, Tony wrote:
> Yes. The question is whether a #MC that come in the middle of list_rcu_add()
> can safely do list_for_each_entry_rcu() on the same list.
>
> RCU is black magic ... maybe it can do this? Adding Paul.
Yeah, the list traversal might be ok as this is what that list_add does
- you can't encounter an inconsistent list - but we still take
a spinlock on addition and the commit which added it:
7f184275aa30 ("lib, Make gen_pool memory allocator lockless")
says
The lockless operation only works if there is enough memory available.
If new memory is added to the pool a lock has to be still taken. So
any user relying on locklessness has to ensure that sufficient memory
is preallocated.
and this is exactly what we're doing - adding new 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.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Powered by blists - more mailing lists