linux-kernel - Re: [PATCH 2/2] x86/MCE: Add command line option to extend MCE Records pool

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <47901422-ac07-47db-bf44-3f4353e92b1d@paulmck-laptop>
Date: Mon, 12 Feb 2024 12:44:06 -0800
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Borislav Petkov <bp@...en8.de>
Cc: "Luck, Tony" <tony.luck@...el.com>,
	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

On Mon, Feb 12, 2024 at 09:10:38PM +0100, Borislav Petkov wrote:
> 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.

Is the #MC adding new memory, or is the interrupted context 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.

If it is the #MC adding new memory, agreed.

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?

							Thanx, Paul