All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: "Herrenschmidt, Benjamin" <benh@amazon.com>,
	"Saidi, Ali" <alisaidi@amazon.com>,
	jason@lakedaemon.net, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, "Woodhouse,
	David" <dwmw@amazon.co.uk>, "Zilberman, Zeev" <zeev@amazon.com>,
	"Machulsky, Zorik" <zorik@amazon.com>
Subject: Re: [PATCH] irqchip/gic-v3-its: Don't try to move a disabled irq
Date: Wed, 03 Jun 2020 13:44:58 +0100	[thread overview]
Message-ID: <d08bd61ffffe59091f6542b4f75292d1@kernel.org> (raw)
In-Reply-To: <87y2p5fatl.fsf@nanos.tec.linutronix.de>

On 2020-06-02 21:54, Thomas Gleixner wrote:
> "Herrenschmidt, Benjamin" <benh@amazon.com> writes:
>> On Sun, 2020-05-31 at 12:09 +0100, Marc Zyngier wrote:
>>> > The semantic of activate/deactivate (which maps to started/shutdown
>>> > in the IRQ code) is that the HW resources for a given interrupt are
>>> > only committed when the interrupt is activated. Trying to perform
>>> > actions involving the HW on an interrupt that isn't active cannot be
>>> > guaranteed to take effect.
>>> >
>>> > I'd rather address it in the core code, by preventing set_affinity (and
>>> > potentially others) to take place when the interrupt is not in the
>>> > STARTED state. Userspace would get an error, which is perfectly
>>> > legitimate, and which it already has to deal with it for plenty of
>>> > other
>>> > reasons.
>> 
>> So I finally found time to dig a bit in there :) Code has changed a 
>> bit
>> since last I looked. But I have memories of the startup code messing
>> around with the affinity, and here it is. In irq_startup() :
>> 
>> 
>> 		switch (__irq_startup_managed(desc, aff, force)) {
>> 		case IRQ_STARTUP_NORMAL:
>> 			ret = __irq_startup(desc);
>> 			irq_setup_affinity(desc);
>> 			break;
>> 		case IRQ_STARTUP_MANAGED:
>> 			irq_do_set_affinity(d, aff, false);
>> 			ret = __irq_startup(desc);

Grump. Nice catch. In hindsight, this is obvious, as managed interrupts
may have been allocated to target CPUs that have been hot-plugged off.

>> 			break;
>> 		case IRQ_STARTUP_ABORT:
>> 			irqd_set_managed_shutdown(d);
>> 			return 0;
>> 
>> So we have two cases here. Normal and managed.
>> 
>> In the managed case, we set the affinity before startup. I feel like 
>> your
>> patch might break that or am I missing something ?
> 
> It will break stuff because the affinity is not stored in case that the
> interrupt is not started.
> 
> I think we can fix this in the core code but that needs more thought.
> __irq_can_set_affinity() is definitely the wrong place.

Indeed. I completely missed the above. Back to square one.

Thanks,

         M.
-- 
Jazz is not dead. It just smells funny...

WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: "Herrenschmidt, Benjamin" <benh@amazon.com>,
	jason@lakedaemon.net, "Machulsky, Zorik" <zorik@amazon.com>,
	linux-kernel@vger.kernel.org, "Saidi, Ali" <alisaidi@amazon.com>,
	"Zilberman, Zeev" <zeev@amazon.com>,
	"Woodhouse, David" <dwmw@amazon.co.uk>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] irqchip/gic-v3-its: Don't try to move a disabled irq
Date: Wed, 03 Jun 2020 13:44:58 +0100	[thread overview]
Message-ID: <d08bd61ffffe59091f6542b4f75292d1@kernel.org> (raw)
In-Reply-To: <87y2p5fatl.fsf@nanos.tec.linutronix.de>

On 2020-06-02 21:54, Thomas Gleixner wrote:
> "Herrenschmidt, Benjamin" <benh@amazon.com> writes:
>> On Sun, 2020-05-31 at 12:09 +0100, Marc Zyngier wrote:
>>> > The semantic of activate/deactivate (which maps to started/shutdown
>>> > in the IRQ code) is that the HW resources for a given interrupt are
>>> > only committed when the interrupt is activated. Trying to perform
>>> > actions involving the HW on an interrupt that isn't active cannot be
>>> > guaranteed to take effect.
>>> >
>>> > I'd rather address it in the core code, by preventing set_affinity (and
>>> > potentially others) to take place when the interrupt is not in the
>>> > STARTED state. Userspace would get an error, which is perfectly
>>> > legitimate, and which it already has to deal with it for plenty of
>>> > other
>>> > reasons.
>> 
>> So I finally found time to dig a bit in there :) Code has changed a 
>> bit
>> since last I looked. But I have memories of the startup code messing
>> around with the affinity, and here it is. In irq_startup() :
>> 
>> 
>> 		switch (__irq_startup_managed(desc, aff, force)) {
>> 		case IRQ_STARTUP_NORMAL:
>> 			ret = __irq_startup(desc);
>> 			irq_setup_affinity(desc);
>> 			break;
>> 		case IRQ_STARTUP_MANAGED:
>> 			irq_do_set_affinity(d, aff, false);
>> 			ret = __irq_startup(desc);

Grump. Nice catch. In hindsight, this is obvious, as managed interrupts
may have been allocated to target CPUs that have been hot-plugged off.

>> 			break;
>> 		case IRQ_STARTUP_ABORT:
>> 			irqd_set_managed_shutdown(d);
>> 			return 0;
>> 
>> So we have two cases here. Normal and managed.
>> 
>> In the managed case, we set the affinity before startup. I feel like 
>> your
>> patch might break that or am I missing something ?
> 
> It will break stuff because the affinity is not stored in case that the
> interrupt is not started.
> 
> I think we can fix this in the core code but that needs more thought.
> __irq_can_set_affinity() is definitely the wrong place.

Indeed. I completely missed the above. Back to square one.

Thanks,

         M.
-- 
Jazz is not dead. It just smells funny...

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-06-03 12:45 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-29  1:55 [PATCH] irqchip/gic-v3-its: Don't try to move a disabled irq Ali Saidi
2020-05-29  1:55 ` Ali Saidi
2020-05-29  4:07 ` Zenghui Yu
2020-05-29  4:07   ` Zenghui Yu
2020-05-29  8:32 ` Marc Zyngier
2020-05-29  8:32   ` Marc Zyngier
2020-05-29 12:36   ` Saidi, Ali
2020-05-29 12:36     ` Saidi, Ali
2020-05-30 16:49     ` Marc Zyngier
2020-05-30 16:49       ` Marc Zyngier
2020-05-31 11:09       ` Marc Zyngier
2020-05-31 11:09         ` Marc Zyngier
2020-06-01  0:10         ` Saidi, Ali
2020-06-01  0:10           ` Saidi, Ali
2020-06-01  2:40         ` Herrenschmidt, Benjamin
2020-06-01  2:40           ` Herrenschmidt, Benjamin
2020-06-02 20:54           ` Thomas Gleixner
2020-06-02 20:54             ` Thomas Gleixner
2020-06-03 12:44             ` Marc Zyngier [this message]
2020-06-03 12:44               ` Marc Zyngier
2020-05-31  2:53 ` kbuild test robot
2020-05-31  2:53   ` kbuild test robot
2020-05-31  2:53   ` kbuild test robot
2020-07-17 21:34 ` [tip: irq/urgent] genirq/affinity: Handle affinity setting on inactive interrupts correctly tip-bot2 for Thomas Gleixner
2020-06-02 18:47 [PATCH] irqchip/gic-v3-its: Don't try to move a disabled irq Saidi, Ali
2020-06-03 15:16 ` Marc Zyngier
2020-06-03 15:16   ` Marc Zyngier
2020-06-03 22:14   ` Herrenschmidt, Benjamin
2020-06-03 22:14     ` Herrenschmidt, Benjamin
2020-06-08 13:48     ` Thomas Gleixner
2020-06-08 13:48       ` Thomas Gleixner
2020-06-08 21:59       ` Benjamin Herrenschmidt
2020-06-08 21:59         ` Benjamin Herrenschmidt
2020-06-08 23:36         ` Thomas Gleixner
2020-06-08 23:36           ` Thomas Gleixner
2020-06-11 17:44 Saidi, Ali

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=d08bd61ffffe59091f6542b4f75292d1@kernel.org \
    --to=maz@kernel.org \
    --cc=alisaidi@amazon.com \
    --cc=benh@amazon.com \
    --cc=dwmw@amazon.co.uk \
    --cc=jason@lakedaemon.net \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=zeev@amazon.com \
    --cc=zorik@amazon.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.