[PATCH] arm64: do not force irq affinity setting
Will Deacon
will.deacon at arm.com
Thu Jun 26 06:11:05 PDT 2014
On Thu, Jun 26, 2014 at 01:00:24PM +0100, Prashant Gaikwad wrote:
> On Thu, 2014-06-26 at 15:50 +0530, Will Deacon wrote:
> > On Thu, Jun 26, 2014 at 07:49:55AM +0100, Prashant Gaikwad wrote:
> > > Unconditional copying cpu_online_mask to affinity
> > > may result in migrating affinity to wrong CPU.
> >
> > We have a bug, but I don't follow your reasoning.
> >
> > > For example, IRQ 5 affinity mask contains CPU 4-7,
> >
> > Ok, so d->affinity is 0xf0...
> >
> > > it was affined to CPU4 and CPU 0-7 are online.
> >
> > ...and cpu_online_mask is 0xff.
> >
> > > Now if we hot-unplug CPU4 then with current
> > > implementation affinity mask will contain
> > > CPU 0-3,5-7 and IRQ 5 will be affined to CPU0.
> >
> > cpumask_any_and(affinity, cpu_online_mask) will give return < nr_cpu_ids
> > since there is an intersection of 0xf0. That means ret is false.
> >
> > The bug is that we then do affinity = cpu_online_mask; unconditionally,
> > but we *won't* do the cpumask_copy, since ret is false.
> >
>
> We do not copy but the affinity mask passed to irq_set_affinity function
> is nothing but cpu_online_mask. So in GIC it will set affinity to CPU0.
Exactly, but your proposed patch changed more than that.
> > You can fix this by simply bringing the arm64 code into line with the arm
> > code, which begs the question as to why this has to exist in the arch/
> > backend at all!
>
> Where can we move this code?
kernel/irq/migration.c?
Will
More information about the linux-arm-kernel
mailing list