[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ce13a36e-967c-c7ec-fd34-d53262313a5d@huawei.com>
Date: Mon, 2 Nov 2020 17:32:32 +0000
From: John Garry <john.garry@...wei.com>
To: Thomas Gleixner <tglx@...utronix.de>, <gregkh@...uxfoundation.org>,
<rafael@...nel.org>, <martin.petersen@...cle.com>,
<jejb@...ux.ibm.com>
CC: <linuxarm@...wei.com>, <linux-scsi@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <maz@...nel.org>
Subject: Re: [PATCH v2 1/3] genirq/affinity: Add irq_update_affinity_desc()
On 28/10/2020 18:22, Thomas Gleixner wrote:
> On Wed, Oct 28 2020 at 20:33, John Garry wrote:
Hi Thomas,
>>
>> +int irq_update_affinity_desc(unsigned int irq,
>> + struct irq_affinity_desc *affinity)
>> +{
>> + unsigned long flags;
>> + struct irq_desc *desc = irq_get_desc_lock(irq, &flags, 0);
>> +
>> + if (!desc)
>> + return -EINVAL;
> Just looking at it some more. This needs a check whether the interrupt
> is actually shut down. Otherwise the update will corrupt
> state. Something like this:
>
> if (irqd_is_started(&desc->irq_data))
> return -EBUSY;
>
> But all of this can't work on x86 due to the way how vector allocation
> works. Let me think about that.
>
Is the problem that we reserve per-cpu managed interrupt space when
allocated irq vectors on x86, and so later changing managed vs
non-managed setting for irqs messes up this accounting somehow?
Cheers,
John
Powered by blists - more mailing lists