Messages in this thread | | | Date | Mon, 12 Feb 2024 12:44:06 -0800 | From | "Paul E. McKenney" <> | 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
| |