linux-kernel - RE: [PATCH v3] scsi: aacraid: Fix reply queue mapping to CPUs based on IRQ affinity

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:
 <PH7PR11MB75708E49B0C0714421E2812FFA48A@PH7PR11MB7570.namprd11.prod.outlook.com>
Date: Thu, 10 Jul 2025 06:49:36 +0000
From: <Sagar.Biradar@...rochip.com>
To: <john.g.garry@...cle.com>, <jmeneghi@...hat.com>,
	<James.Bottomley@...senPartnership.com>, <martin.petersen@...cle.com>,
	<linux-scsi@...r.kernel.org>, <aacraid@...rosemi.com>, <corbet@....net>
CC: <linux-doc@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<thenzl@...hat.com>, <Scott.Benesh@...rochip.com>, <Don.Brace@...rochip.com>,
	<Tom.White@...rochip.com>, <Abhinav.Kuchibhotla@...rochip.com>,
	<mpatalan@...hat.com>, <Raja.VS@...rochip.com>
Subject: RE: [PATCH v3] scsi: aacraid: Fix reply queue mapping to CPUs based
 on IRQ affinity



> -----Original Message-----
> From: John Garry <john.g.garry@...cle.com>
> Sent: Thursday, June 19, 2025 3:47 AM
> To: John Meneghini <jmeneghi@...hat.com>;
> James.Bottomley@...senPartnership.com; martin.petersen@...cle.com;
> linux-scsi@...r.kernel.org; aacraid@...rosemi.com; corbet@....net
> Cc: linux-doc@...r.kernel.org; linux-kernel@...r.kernel.org;
> thenzl@...hat.com; Scott Benesh - C33703 <Scott.Benesh@...rochip.com>;
> Don Brace - C33706 <Don.Brace@...rochip.com>; Tom White - C33503
> <Tom.White@...rochip.com>; Abhinav Kuchibhotla - C70322
> <Abhinav.Kuchibhotla@...rochip.com>; Sagar Biradar - C34249
> <Sagar.Biradar@...rochip.com>; mpatalan@...hat.com
> Subject: Re: [PATCH v3] scsi: aacraid: Fix reply queue mapping to CPUs based
> on IRQ affinity
> 
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
> 
> On 18/06/2025 20:24, John Meneghini wrote:
> > From: Sagar Biradar <sagar.biradar@...rochip.com>
> >
> > From: Sagar Biradar <sagar.biradar@...rochip.com>
> >
> > This patch fixes a bug in the original path that caused I/O hangs. The
> > I/O hangs were because of an MSIx vector not having a mapped online CPU
> > upon receiving completion.
> >
> > This patch enables Multi-Q support in the aacriad driver. Multi-Q support
> > in the driver is needed to support CPU offlining.
> 
> I assume that you mean "safe" CPU offlining.
> 
> It seems to me that in all cases we use queue interrupt affinity
> spreading and managed interrupts for MSIX, right?
> 
> See aac_define_int_mode() -> pci_alloc_irq_vectors(..., PCI_IRQ_MSIX |
> PCI_IRQ_AFFINITY);
> 
> But then for this non- Multi-Q support, the queue seems to be chosen
> based on a round-robin approach in the driver. That round-robin comes
> from how fib.vector_no is assigned in aac_fib_vector_assign(). If this
> is the case, then why are managed interrupts being used for this non-
> Multi-Q support at all?
> 
> I may be wrong about this. That driver is hard to understand with so
> many knobs.
> 


Thank you very much for raising this — you're right that using PCI_IRQ_AFFINITY in non-MultiQ mode doesn’t offer real value, since the driver doesn’t utilize the affinity mapping.
That said, the current implementation is functionally correct and consistent with the driver’s historical behavior. 
To keep the patch focused and avoid scope creep, I’d prefer to leave the affinity flag logic as is for now.

I’d be happy to follow up with a small cleanup patch, sometime in future, to improve this if you think it would help.

Thanks