netdev - Re: [PATCH 7/9] ethernet: stmicro: Simplify PCI devres usage

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: <d34214f18f994d255f640aefdf7f31814faa76f1.camel@redhat.com>
Date: Tue, 20 Aug 2024 12:53:03 +0200
From: Philipp Stanner <pstanner@...hat.com>
To: Andy Shevchenko <andy@...nel.org>
Cc: onathan Corbet <corbet@....net>, Jens Axboe <axboe@...nel.dk>, Wu Hao
 <hao.wu@...el.com>, Tom Rix <trix@...hat.com>, Moritz Fischer
 <mdf@...nel.org>,  Xu Yilun <yilun.xu@...el.com>, Linus Walleij
 <linus.walleij@...aro.org>, Bartosz Golaszewski <brgl@...ev.pl>, "David S.
 Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub
 Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Alexandre
 Torgue <alexandre.torgue@...s.st.com>, Jose Abreu <joabreu@...opsys.com>,
 Maxime Coquelin <mcoquelin.stm32@...il.com>, Bjorn Helgaas
 <bhelgaas@...gle.com>, Alvaro Karsz <alvaro.karsz@...id-run.com>, "Michael
 S. Tsirkin" <mst@...hat.com>, Jason Wang <jasowang@...hat.com>, Xuan Zhuo
 <xuanzhuo@...ux.alibaba.com>,  Eugenio Pérez
 <eperezma@...hat.com>, Richard Cochran <richardcochran@...il.com>, Mark
 Brown <broonie@...nel.org>, David Lechner <dlechner@...libre.com>, Uwe
 Kleine-König <u.kleine-koenig@...gutronix.de>, Jonathan
 Cameron <Jonathan.Cameron@...wei.com>,  Hannes Reinecke <hare@...e.de>,
 Damien Le Moal <dlemoal@...nel.org>, Chaitanya Kulkarni <kch@...dia.com>,
 "Martin K. Petersen" <martin.petersen@...cle.com>, 
 linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org, 
 linux-block@...r.kernel.org, linux-fpga@...r.kernel.org, 
 linux-gpio@...r.kernel.org, netdev@...r.kernel.org, 
 linux-stm32@...md-mailman.stormreply.com,
 linux-arm-kernel@...ts.infradead.org,  linux-pci@...r.kernel.org,
 virtualization@...ts.linux.dev
Subject: Re: [PATCH 7/9] ethernet: stmicro: Simplify PCI devres usage

On Tue, 2024-08-20 at 13:37 +0300, Andy Shevchenko wrote:
> On Tue, Aug 20, 2024 at 09:52:40AM +0200, Philipp Stanner wrote:
> > On Mon, 2024-08-19 at 21:28 +0300, Andy Shevchenko wrote:
> > > On Mon, Aug 19, 2024 at 06:51:47PM +0200, Philipp Stanner wrote:
> 
> ...
> 
> > > loongson_dwmac_probe()
> > > 
> > > > +	memset(&res, 0, sizeof(res));
> > > > +	res.addr = pcim_iomap_region(pdev, 0, pci_name(pdev));
> > > > +	if (IS_ERR(res.addr)) {
> > > > +		ret = PTR_ERR(res.addr);
> > > > +		goto err_disable_device;
> > > 
> > > It seems your series reveals issues in the error paths of
> > > .probe():s
> > > in many drivers...
> > > 
> > > If we use pcim variant to enable device, why do we need to
> > > explicitly
> > > disable it?
> > 
> > No.
> 
> Can you elaborate? No issues being revealed, or no need to disable it
> explicitly, or...?

Oh, my bad, I overlooked your "why" in that question.

We do not explicitly have to disable it. It's wrong / unnecessary, as
many of the other calls you criticized in this series.

pcim_enable_device() (in pci/devres.c) calls devm_add_action(...,
pcim_disable_device,  ...), which will disable the device on driver
detach.

So the call of pci_disable_device() above is redundant. We could remove
it.

> 
> > > >  	}
> 
> ...
> 
> > > loongson_dwmac_remove()
> > > 
> > > >  	pci_disable_msi(pdev);
> > > >  	pci_disable_device(pdev);
> > > 
> > > Not sure why we need these either...
> > 
> > It's complicated.
> > 
> > The code uses pciM_enable_device(), but here in remove
> > pci_disable_device().
> > 
> > pcim_enable_device() sets up a disable callback which only calls
> > pci_disable_device() if pcim_pin_device() has not been called.
> > 
> > This code doesn't seem to call pcim_pin_device(), so I think
> > pci_disable_device() could be removed.
> > 
> > 
> > I definitely would not feel confident touching pci_disable_msi(),
> > though. The AFAIK biggest problem remaining in PCI devres is that
> > the
> > MSI code base implicitly calls into devres, see here [1]
> 
> But isn't it a busyness of PCI core to call pci_disable_msi() at the
> right
> moment? Okay, I admit that there might be devices that require a
> special
> workflow WRT MSI, is this the case here?

I don't know enough about how MSI is intended to be used.

>From what I've seen in the code base, pcim_setup_msi_release() does
register a devres callback that will indeed call pci_disable_msi()
after some intermediate calls.

But in my honest opinion, that code is _very_ broken. I was thinking
about how we might clean it up, but couldn't come up with an idea yet.

Only after the code in pci/msi/ has been cleanly separated from
implicit devres I myself would start touching function calls related to
MSI.

That being said, I suspect that one can remove pci_disable_msi() in the
line above. But the risk-benefit-ratio doesn't pay off for me.

P.

> 
> > [1]
> > https://lore.kernel.org/all/ee44ea7ac760e73edad3f20b30b4d2fff66c1a85.camel@redhat.com/
>