linux-kernel - Re: [PATCH v2] PCI: Restore the original INTX_DISABLE bit by pcim

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] [day] [month] [year] [list]

Message-ID: <874j1jbeaq.wl-tiwai@suse.de>
Date: Tue, 28 Jan 2025 08:14:37 +0100
From: Takashi Iwai <tiwai@...e.de>
To: Bjorn Helgaas <helgaas@...nel.org>
Cc: Takashi Iwai <tiwai@...e.de>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Philipp Stanner <pstanner@...hat.com>,
	linux-pci@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] PCI: Restore the original INTX_DISABLE bit by pcim_intx()

On Mon, 27 Jan 2025 19:58:53 +0100,
Bjorn Helgaas wrote:
> 
> On Mon, Jan 27, 2025 at 05:00:25PM +0100, Takashi Iwai wrote:
> > On Mon, 09 Dec 2024 14:15:19 +0100,
> > Philipp Stanner wrote:
> > > 
> > > On Mon, 2024-11-04 at 10:14 +0100, Philipp Stanner wrote:
> > > > On Thu, 2024-10-31 at 14:42 +0100, Takashi Iwai wrote:
> > > > > pcim_intx() tries to restore the INTx bit at removal via devres,
> > > > > but
> > > > > there is a chance that it restores a wrong value.
> > > > > Because the value to be restored is blindly assumed to be the
> > > > > negative
> > > > > of the enable argument, when a driver calls pcim_intx()
> > > > > unnecessarily
> > > > > for the already enabled state, it'll restore to the disabled state
> > > > > in
> > > > > turn.  That is, the function assumes the case like:
> > > > > 
> > > > >   // INTx == 1
> > > > >   pcim_intx(pdev, 0); // old INTx value assumed to be 1 -> correct
> > > > > 
> > > > > but it might be like the following, too:
> > > > > 
> > > > >   // INTx == 0
> > > > >   pcim_intx(pdev, 0); // old INTx value assumed to be 1 -> wrong
> > > > > 
> > > > > Also, when a driver calls pcim_intx() multiple times with different
> > > > > enable argument values, the last one will win no matter what value
> > > > > it
> > > > > is.  This can lead to inconsistency, e.g.
> > > > > 
> > > > >   // INTx == 1
> > > > >   pcim_intx(pdev, 0); // OK
> > > > >   ...
> > > > >   pcim_intx(pdev, 1); // now old INTx wrongly assumed to be 0
> > > > > 
> > > > > This patch addresses those inconsistencies by saving the original
> > > > > INTx state at the first pcim_intx() call.  For that,
> > > > > get_or_create_intx_devres() is folded into pcim_intx() caller side;
> > > > > it allows us to simply check the already allocated devres and
> > > > > record
> > > > > the original INTx along with the devres_alloc() call.
> > > > > 
> > > > > Fixes: 25216afc9db5 ("PCI: Add managed pcim_intx()")
> > > > > Cc: stable@...r.kernel.org # 6.11+
> > > > > Link: https://lore.kernel.org/87v7xk2ps5.wl-tiwai@suse.de
> > > > > Signed-off-by: Takashi Iwai <tiwai@...e.de>
> > > > 
> > > > Reviewed-by: Philipp Stanner <pstanner@...hat.com>
> > > 
> > > Hello,
> > > 
> > > it seems we forgot about this patch.
> > > 
> > > Regards,
> > > P.
> > 
> > This has fallen through the cracks.
> > Do I need to resubmit?
> 
> Oops, sorry, I did miss this.  I added to pci/for-linus for v6.14.  It
> didn't apply quite cleanly, so take a look and make sure I resolved it
> correctly:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git/commit/?h=for-linus&id=d555ed45a5a10a813528c7685f432369d536ae3d

Looks good to me.  Thanks!


Takashi