linux-kernel - Re: [RFC PATCH v1 2/4] irqchip: GICv3: set non-percpu irqs status with _IRQ_MOVE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.11.1509071502080.15006@nanos>
Date:	Mon, 7 Sep 2015 15:24:01 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Marc Zyngier <marc.zyngier@....com>
cc:	Jiang Liu <jiang.liu@...ux.intel.com>,
	Yang Yingliang <yangyingliang@...wei.com>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	Mark Rutland <mark.rutland@....com>,
	Will Deacon <will.deacon@....com>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	Hanjun Guo <hanjun.guo@...aro.org>
Subject: Re: [RFC PATCH v1 2/4] irqchip: GICv3: set non-percpu irqs status
 with _IRQ_MOVE_PCNTXT

On Mon, 7 Sep 2015, Marc Zyngier wrote:
> On 06/09/15 06:56, Jiang Liu wrote:
> > On 2015/9/6 12:23, Yang Yingliang wrote:
> >> Use irq_settings_set_move_pcntxt() helper irqs status with
> >> _IRQ_MOVE_PCNTXT. So that it can do set affinity when calling
> >> irq_set_affinity_locked().
> > Hi Yingliang,
> > 	We could only set _IRQ_MOVE_PCNTCT flag to enable migrating
> > IRQ in process context if your hardware platform supports atomically
> > change IRQ configuration. Not sure whether that's true for GICv3.
> > If GICv3 doesn't support atomically change irq configuration, this
> > change may cause trouble.
> 
> I think it boils down to what exactly "process context" means here. If
> this means "we do not need to mask the interrupt" while moving it, then
> it should be fine (the GIC architecture guarantees that a pending
> interrupt will be migrated).
> 
> Is there any other requirement for this flag?

The history of this flag is as follows:

On x86 interrupts can only be safely migrated while the interrupt is
handled. With the introduction of IRQ remapping this requirement
changed. Remapped interrupts can be migrated in any context.

If you look at irq_set_affinity_locked()

   if (irq_can_move_pcntxt(data) {
      irq_do_set_affinity(data,...)
        chip->irq_set_affinity(data,...);
   } else {
      irqd_set_move_pending(data);
   }

So if IRQ_MOVE_PCNTXT is not set, we handle the migration of the
interrupt from next the interrupt. If it's set set_affinity() is
called right away.

All architectures which do not select GENERIC_PENDING_IRQ are using
the direct method.

Thanks,

	tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/