[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87czh533dk.ffs@tglx>
Date: Mon, 25 Apr 2022 11:43:03 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Pingfan Liu <kernelfans@...il.com>
Cc: linux-kernel@...r.kernel.org,
Valentin Schneider <valentin.schneider@....com>,
Peter Zijlstra <peterz@...radead.org>,
Frederic Weisbecker <frederic@...nel.org>,
Baokun Li <libaokun1@...wei.com>,
Mark Rutland <mark.rutland@....com>,
Steven Price <steven.price@....com>,
"Jason A. Donenfeld" <Jason@...c4.com>,
Yuan ZhaoXiong <yuanzhaoxiong@...du.com>,
YueHaibing <yuehaibing@...wei.com>,
Randy Dunlap <rdunlap@...radead.org>
Subject: Re: [PATCH 7/9] irq: remove needless lock in takedown_cpu()
On Mon, Apr 25 2022 at 10:57, Pingfan Liu wrote:
> On Thu, Apr 21, 2022 at 06:11:56PM +0200, Thomas Gleixner wrote:
>> > - irq_lock_sparse();
>>
>> Not everything is about RCU here. You really need to look at all moving
>> parts:
>>
>> irq_migrate_all_off_this_cpu() relies on the allocated_irqs bitmap and
>> the sparse tree to be in consistent state, which is only guaranteed when
>> the sparse lock is held.
>>
>
> For the irq which transfer from active to inactive(disappearing) after
> fetching, desc->lock can serve the sync purpose. In this case,
> irq_lock_sparse() is not needed. For a emergeing irq, I am not sure
> about it.
No, it's required for the free case. The alloc case is
uninteresting. Care to look into the code?
irq_free_descs()
lock(sparse);
free_descs();
bitmap_clear(allocated_irqs, from, cnt);
unlock_sparse);
As free_descs() sets the sparse tree entry to NULL, up to the point
where bitmap_clear() finishes the state is inconsistent.
Now look at irq_migrate_all_off_this_cpu() and figure out what happens
when stop_machine() hits into the inconsistent state.
This can be fixed, but not by making mysterious claims about RCU and
desc->lock.
Thanks,
tglx
Powered by blists - more mailing lists