All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Pingfan Liu <kernelfans@gmail.com>
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: Mon, 25 Apr 2022 11:43:03 +0200	[thread overview]
Message-ID: <87czh533dk.ffs@tglx> (raw)
In-Reply-To: <YmYOAfz3Oh1bYiVi@piliu.users.ipa.redhat.com>

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

  reply	other threads:[~2022-04-25  9:43 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 [this message]
2022-04-27  6:01         ` Pingfan Liu
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=87czh533dk.ffs@tglx \
    --to=tglx@linutronix.de \
    --cc=Jason@zx2c4.com \
    --cc=frederic@kernel.org \
    --cc=kernelfans@gmail.com \
    --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=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.