netdev - Re: [RFC PATCH 01/13] PCI: Prepare removing devres from pci

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: <f65e9fa01a1947782fc930876e5f84174408db67.camel@redhat.com>
Date: Fri, 11 Oct 2024 14:16:06 +0200
From: Philipp Stanner <pstanner@...hat.com>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
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>, Mario Limonciello <mario.limonciello@....com>, Chen
 Ni <nichen@...as.ac.cn>, 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>, Mostafa Saleh
 <smostafa@...gle.com>, Hannes Reinecke <hare@...e.de>, John Garry
 <john.g.garry@...cle.com>, Soumya Negi <soumya.negi97@...il.com>, Jason
 Gunthorpe <jgg@...pe.ca>, Yi Liu <yi.l.liu@...el.com>, "Dr. David Alan
 Gilbert" <linux@...blig.org>, Christian Brauner <brauner@...nel.org>, Ankit
 Agrawal <ankita@...dia.com>, Reinette Chatre <reinette.chatre@...el.com>,
 Eric Auger <eric.auger@...hat.com>, Ye Bin <yebin10@...wei.com>, Marek
 Marczykowski-Górecki <marmarek@...isiblethingslab.com>,
 Pierre-Louis Bossart <pierre-louis.bossart@...ux.dev>, Maarten Lankhorst
 <maarten.lankhorst@...ux.intel.com>, Kai Vehmanen
 <kai.vehmanen@...ux.intel.com>,  Peter Ujfalusi
 <peter.ujfalusi@...ux.intel.com>, Rui Salvaterra <rsalvaterra@...il.com>,
 Marc Zyngier <maz@...nel.org>, 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, 
 linux-staging@...ts.linux.dev, kvm@...r.kernel.org, 
 xen-devel@...ts.xenproject.org, linux-sound@...r.kernel.org
Subject: Re: [RFC PATCH 01/13] PCI: Prepare removing devres from pci_intx()

On Thu, 2024-10-10 at 17:40 +0300, Andy Shevchenko wrote:
> On Wed, Oct 09, 2024 at 10:35:07AM +0200, Philipp Stanner wrote:
> > pci_intx() is a hybrid function which sometimes performs devres
> > operations, depending on whether pcim_enable_device() has been used
> > to
> > enable the pci_dev. This sometimes-managed nature of the function
> > is
> > problematic. Notably, it causes the function to allocate under some
> > circumstances which makes it unusable from interrupt context.
> > 
> > To, ultimately, remove the hybrid nature from pci_intx(), it is
> > first
> > necessary to provide an always-managed and a never-managed version
> > of that function. Then, all callers of pci_intx() can be ported to
> > the
> > version they need, depending whether they use pci_enable_device()
> > or
> > pcim_enable_device().
> > 
> > An always-managed function exists, namely pcim_intx(), for which
> > __pcim_intx(), a never-managed version of pci_intx() had been
> > implemented.
> 
> > Make __pcim_intx() a public function under the name
> > pci_intx_unmanaged(). Make pcim_intx() a public function.
> 
> To avoid an additional churn we can make just completely new APIs,
> namely:
> pcim_int_x()
> pci_int_x()
> 
> You won't need all dirty dances with double underscored function
> naming and
> renaming.

Ähm.. I can't follow. The new version doesn't use double underscores
anymore. __pcim_intx() is being removed, effectively.
After this series, we'd end up with a clean:

	pci_intx() <-> pcim_intx()

just as in the other PCI APIs.


> 
> 
> ...
> 
> > +	pci_read_config_word(pdev, PCI_COMMAND, &pci_command);
> > +
> > +	if (enable)
> > +		new = pci_command & ~PCI_COMMAND_INTX_DISABLE;
> > +	else
> > +		new = pci_command | PCI_COMMAND_INTX_DISABLE;
> > +
> > +	if (new != pci_command)
> 
> I would use positive conditionals as easy to read (yes, a couple of
> lines
> longer, but also a win is the indentation and avoiding an additional
> churn in
> the future in case we need to add something in this branch.

I can't follow. You mean:

if (new == pci_command)
    return;

?

That's exactly the same level of indentation. Plus, I just copied the
code.

> 
> > +		pci_write_config_word(pdev, PCI_COMMAND, new);
> 
> ...
> 
> Otherwise I'm for the idea in general.

\o/

>