| 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
| ||
|
Message-ID: <aec23bb79b9ff7dd7f13eb67460e0605eac22912.camel@redhat.com>
Date: Thu, 24 Oct 2024 10:02:59 +0200
From: Philipp Stanner <pstanner@...hat.com>
To: Takashi Iwai <tiwai@...e.de>
Cc: Damien Le Moal <dlemoal@...nel.org>, Niklas Cassel <cassel@...nel.org>,
Sergey Shtylyov <s.shtylyov@....ru>, Basavaraj Natikar
<basavaraj.natikar@....com>, Jiri Kosina <jikos@...nel.org>, Benjamin
Tissoires <bentiss@...nel.org>, Arnd Bergmann <arnd@...db.de>, Greg
Kroah-Hartman <gregkh@...uxfoundation.org>, Alex Dubov <oakad@...oo.com>,
Sudarsana Kalluru <skalluru@...vell.com>, Manish Chopra
<manishc@...vell.com>, "David S. Miller" <davem@...emloft.net>, Eric
Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo
Abeni <pabeni@...hat.com>, Rasesh Mody <rmody@...vell.com>,
GR-Linux-NIC-Dev@...vell.com, Igor Mitsyanko <imitsyanko@...ntenna.com>,
Sergey Matyukevich <geomatsi@...il.com>, Kalle Valo <kvalo@...nel.org>,
Sanjay R Mehta <sanju.mehta@....com>, Shyam Sundar S K
<Shyam-sundar.S-k@....com>, Jon Mason <jdmason@...zu.us>, Dave Jiang
<dave.jiang@...el.com>, Allen Hubbe <allenbh@...il.com>, Bjorn Helgaas
<bhelgaas@...gle.com>, Alex Williamson <alex.williamson@...hat.com>,
Juergen Gross <jgross@...e.com>, Stefano Stabellini
<sstabellini@...nel.org>, Oleksandr Tyshchenko
<oleksandr_tyshchenko@...m.com>, Jaroslav Kysela <perex@...ex.cz>, Takashi
Iwai <tiwai@...e.com>, Chen Ni <nichen@...as.ac.cn>, Mario Limonciello
<mario.limonciello@....com>, Ricky Wu <ricky_wu@...ltek.com>, Al Viro
<viro@...iv.linux.org.uk>, Breno Leitao <leitao@...ian.org>, Kevin Tian
<kevin.tian@...el.com>, Thomas Gleixner <tglx@...utronix.de>, Ilpo
Järvinen <ilpo.jarvinen@...ux.intel.com>, Andy
Shevchenko <andriy.shevchenko@...ux.intel.com>, Mostafa Saleh
<smostafa@...gle.com>, Jason Gunthorpe <jgg@...pe.ca>, Yi Liu
<yi.l.liu@...el.com>, Christian Brauner <brauner@...nel.org>, Ankit
Agrawal <ankita@...dia.com>, Eric Auger <eric.auger@...hat.com>, Reinette
Chatre <reinette.chatre@...el.com>, Ye Bin <yebin10@...wei.com>, Marek
Marczykowski-Górecki <marmarek@...isiblethingslab.com>,
Pierre-Louis Bossart <pierre-louis.bossart@...ux.dev>, Peter Ujfalusi
<peter.ujfalusi@...ux.intel.com>, Maarten Lankhorst
<maarten.lankhorst@...ux.intel.com>, Kai Vehmanen
<kai.vehmanen@...ux.intel.com>, Rui Salvaterra <rsalvaterra@...il.com>,
linux-ide@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-input@...r.kernel.org, netdev@...r.kernel.org,
linux-wireless@...r.kernel.org, ntb@...ts.linux.dev,
linux-pci@...r.kernel.org, kvm@...r.kernel.org,
xen-devel@...ts.xenproject.org, linux-sound@...r.kernel.org
Subject: Re: [PATCH 02/13] ALSA: hda_intel: Use always-managed version of
pcim_intx()
On Wed, 2024-10-23 at 17:03 +0200, Takashi Iwai wrote:
> On Wed, 23 Oct 2024 15:50:09 +0200,
> Philipp Stanner wrote:
> >
> > On Tue, 2024-10-22 at 16:08 +0200, Takashi Iwai wrote:
> > > On Tue, 15 Oct 2024 20:51:12 +0200,
> > > Philipp Stanner wrote:
> > > >
> > > > pci_intx() is a hybrid function which can sometimes be managed
> > > > through
> > > > devres. To remove this hybrid nature from pci_intx(), it is
> > > > necessary to
> > > > port users to either an always-managed or a never-managed
> > > > version.
> > > >
> > > > hda_intel enables its PCI-Device with pcim_enable_device().
> > > > Thus,
> > > > it needs
> > > > the always-managed version.
> > > >
> > > > Replace pci_intx() with pcim_intx().
> > > >
> > > > Signed-off-by: Philipp Stanner <pstanner@...hat.com>
> > > > ---
> > > > sound/pci/hda/hda_intel.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/sound/pci/hda/hda_intel.c
> > > > b/sound/pci/hda/hda_intel.c
> > > > index b4540c5cd2a6..b44ca7b6e54f 100644
> > > > --- a/sound/pci/hda/hda_intel.c
> > > > +++ b/sound/pci/hda/hda_intel.c
> > > > @@ -786,7 +786,7 @@ static int azx_acquire_irq(struct azx
> > > > *chip,
> > > > int do_disconnect)
> > > > }
> > > > bus->irq = chip->pci->irq;
> > > > chip->card->sync_irq = bus->irq;
> > > > - pci_intx(chip->pci, !chip->msi);
> > > > + pcim_intx(chip->pci, !chip->msi);
> > > > return 0;
> > > > }
> > > >
> > >
> > > Hm, it's OK-ish to do this as it's practically same as what
> > > pci_intx()
> > > currently does. But, the current code can be a bit inconsistent
> > > about
> > > the original intx value. pcim_intx() always stores !enable to
> > > res->orig_intx unconditionally, and it means that the orig_intx
> > > value
> > > gets overridden at each time pcim_intx() gets called.
> >
> > Yes.
> >
> > >
> > > Meanwhile, HD-audio driver does release and re-acquire the
> > > interrupt
> > > after disabling MSI when something goes wrong, and pci_intx()
> > > call
> > > above is a part of that procedure. So, it can rewrite the
> > > res->orig_intx to another value by retry without MSI. And after
> > > the
> > > driver removal, it'll lead to another state.
> >
> > I'm not sure that I understand this paragraph completely. Still,
> > could
> > a solution for the driver on the long-term just be to use
> > pci_intx()?
>
> pci_intx() misses the restore of the original value, so it's no
> long-term solution, either.
Sure that is missing – I was basically asking whether the driver could
live without that feature.
Consider that point obsolete, see below
>
> What I meant is that pcim_intx() blindly assumes the negative of the
> passed argument as the original state, which isn't always true. e.g.
> when the driver calls it twice with different values, a wrong value
> may be remembered.
Ah, I see – thoguh the issue is when it's called several times with the
*same* value, isn't it?
E.g.
pcim_intx(pdev, 1); // 0 is remembered as the old value
pcim_intx(pdev, 1); // 0 is falsely remembered as the old value
Also, it would seem that calling the function for the first time like
that:
pcim_intx(pdev, 0); // old value: 1
is at least incorrect, because INTx should be 0 per default, shouldn't
it? Could then even be a 1st class bug, because INTx would end up being
enabled despite having been disabled all the time.
>
> That said, I thought of something like below.
At first glance that looks like a good idea to me, thanks for working
this out!
IMO you can submit that as a patch so we can discuss it separately.
Greetings,
Philipp
>
>
> thanks,
>
> Takashi
>
> -- 8< --
> --- a/drivers/pci/devres.c
> +++ b/drivers/pci/devres.c
> @@ -438,8 +438,17 @@ static void pcim_intx_restore(struct device
> *dev, void *data)
> __pcim_intx(pdev, res->orig_intx);
> }
>
> -static struct pcim_intx_devres *get_or_create_intx_devres(struct
> device *dev)
> +static void save_orig_intx(struct pci_dev *pdev)
> {
> + u16 pci_command;
> +
> + pci_read_config_word(pdev, PCI_COMMAND, &pci_command);
> + res->orig_intx = !(pci_command & PCI_COMMAND_INTX_DISABLE);
> +}
> +
> +static struct pcim_intx_devres *get_or_create_intx_devres(struct
> pci_dev *pdev)
> +{
> + struct device *dev = &pdev->dev;
> struct pcim_intx_devres *res;
>
> res = devres_find(dev, pcim_intx_restore, NULL, NULL);
> @@ -447,8 +456,10 @@ static struct pcim_intx_devres
> *get_or_create_intx_devres(struct device *dev)
> return res;
>
> res = devres_alloc(pcim_intx_restore, sizeof(*res),
> GFP_KERNEL);
> - if (res)
> + if (res) {
> + save_orig_intx(pdev);
> devres_add(dev, res);
> + }
>
> return res;
> }
> @@ -467,11 +478,10 @@ int pcim_intx(struct pci_dev *pdev, int enable)
> {
> struct pcim_intx_devres *res;
>
> - res = get_or_create_intx_devres(&pdev->dev);
> + res = get_or_create_intx_devres(pdev);
> if (!res)
> return -ENOMEM;
>
> - res->orig_intx = !enable;
> __pcim_intx(pdev, enable);
>
> return 0;
>
Powered by blists - more mailing lists