All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pingfan Liu <kernelfans@gmail.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org,
	Valentin Schneider <valentin.schneider@arm.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Frederic Weisbecker <frederic@kernel.org>,
	Baokun Li <libaokun1@huawei.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Steven Price <steven.price@arm.com>,
	"Jason A. Donenfeld" <Jason@zx2c4.com>,
	Yuan ZhaoXiong <yuanzhaoxiong@baidu.com>,
	YueHaibing <yuehaibing@huawei.com>,
	Randy Dunlap <rdunlap@infradead.org>
Subject: Re: [PATCH 7/9] irq: remove needless lock in takedown_cpu()
Date: Wed, 27 Apr 2022 14:01:55 +0800	[thread overview]
Message-ID: <YmjcUxvct7aw82DH@piliu.users.ipa.redhat.com> (raw)
In-Reply-To: <87czh533dk.ffs@tglx>

On Mon, Apr 25, 2022 at 11:43:03AM +0200, Thomas Gleixner wrote:
> 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?
> 

Yes, it is a good exercise. Thanks for the enlightenment.

> 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.
> 

So the following code should fix the inconsistence between bitmap and
sparse tree.
diff --git a/kernel/irq/cpuhotplug.c b/kernel/irq/cpuhotplug.c
index 1ed2b1739363..cd0d180f082d 100644
--- a/kernel/irq/cpuhotplug.c
+++ b/kernel/irq/cpuhotplug.c
@@ -161,6 +161,8 @@ void irq_migrate_all_off_this_cpu(void)
                bool affinity_broken;

                desc = irq_to_desc(irq);
+               if (!desc)
+                       continue;
                raw_spin_lock(&desc->lock);
                affinity_broken = migrate_one_irq(desc);
                raw_spin_unlock(&desc->lock);

> This can be fixed, but not by making mysterious claims about RCU and
> desc->lock.
> 

But I still think that desc->lock is critical to the consistence of the
irq _affinity_ if removing sparse lock in takedown_cpu().

For the free case, after applying the above patch, it should work.
void irq_migrate_all_off_this_cpu(void)
{
	for_each_active_irq(irq) {

		desc = irq_to_desc(irq);
		if (!desc)
			continue;
			                               ---> if breaking
						       in by free, then
						       migrate_one_irq()
						       will skip it
						       since the irq is
						       not activated any
						       long
		raw_spin_lock(&desc->lock);
		affinity_broken = migrate_one_irq(desc);
		raw_spin_unlock(&desc->lock);
		...
	}
}

But for the alloc case, it could be a problem.
void irq_migrate_all_off_this_cpu(void)
{
	for_each_active_irq(irq) {

		desc = irq_to_desc(irq);
		if (!desc)
			continue;
		raw_spin_lock(&desc->lock);
		affinity_broken = migrate_one_irq(desc);
		raw_spin_unlock(&desc->lock);
		...
                                                   ---> any new irq will
						   not be detected. But alloc_descs(start, cnt, node, affinity)
						   still associate the
						   irq with this cpu.
						   There is _no_
						   opportunity to clear
						   out this cpu from
						   desc->irq_common_data.affinity.

						   This is the affinity
						   inconsistent problem.
}


Thanks,

	Pingfan

  reply	other threads:[~2022-04-27  6:02 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-20 14:05 [PATCH 0/9] trival fix or improvement about irq_desc access Pingfan Liu
2022-04-20 14:05 ` [PATCH 1/9] irq/irqdesc: put the lock at the exact place in irq_sysfs_init() Pingfan Liu
2022-04-20 14:05 ` [PATCH 2/9] irq/irqdesc: change the name of delete_irq_desc() to irq_delete_desc() Pingfan Liu
2022-04-20 14:05 ` [PATCH 3/9] irq/manage: remove some unreferenced code Pingfan Liu
2022-04-20 20:56   ` Miguel Ojeda
2022-04-20 14:05 ` [PATCH 4/9] s390/irq: utilize RCU instead of irq_lock_sparse() in show_msi_interrupt() Pingfan Liu
2022-04-20 18:16   ` Heiko Carstens
2022-04-21  3:36     ` Pingfan Liu
2022-04-21 11:42       ` Heiko Carstens
2022-04-22  9:56         ` Pingfan Liu
2022-04-22 10:02   ` [PATCHv2] " Pingfan Liu
2022-04-25 11:39     ` Heiko Carstens
2022-04-20 14:05 ` [PATCH 5/9] x86/irq: place for_each_active_irq() in rcu read section Pingfan Liu
2022-04-20 14:05 ` [PATCH 6/9] pm/irq: make for_each_irq_desc() safe of irq_desc release Pingfan Liu
2022-04-20 16:23   ` Rafael J. Wysocki
2022-04-21  3:31     ` Pingfan Liu
2022-04-21 10:57       ` Rafael J. Wysocki
2022-04-22 10:43         ` Pingfan Liu
2022-04-27  6:03   ` [PATCHv2] genirq/PM: Make " Pingfan Liu
2022-04-20 14:05 ` [PATCH 7/9] irq: remove needless lock in takedown_cpu() Pingfan Liu
2022-04-21 16:11   ` Thomas Gleixner
2022-04-25  2:57     ` Pingfan Liu
2022-04-25  9:43       ` Thomas Gleixner
2022-04-27  6:01         ` Pingfan Liu [this message]
2022-04-20 14:05 ` [PATCH 8/9] irq: make irq_lock_sparse() independent of CONFIG_SPARSE_IRQ Pingfan Liu
2022-04-20 14:05 ` [PATCH 9/9] irq/irqdesc: rename sparse_irq_lock to bitmap_lock Pingfan Liu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YmjcUxvct7aw82DH@piliu.users.ipa.redhat.com \
    --to=kernelfans@gmail.com \
    --cc=Jason@zx2c4.com \
    --cc=frederic@kernel.org \
    --cc=libaokun1@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=peterz@infradead.org \
    --cc=rdunlap@infradead.org \
    --cc=steven.price@arm.com \
    --cc=tglx@linutronix.de \
    --cc=valentin.schneider@arm.com \
    --cc=yuanzhaoxiong@baidu.com \
    --cc=yuehaibing@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.