Re: [PATCH 1/2] gpio: amd8111: Convert PCIBIOS_* return codes to errnos

[Ilpo Järvinen]

On Mon, 27 May 2024, Dan Carpenter wrote:
> On Mon, May 27, 2024 at 05:11:32PM +0300, Ilpo Järvinen wrote:
> > On Mon, 27 May 2024, Dan Carpenter wrote:
> > 
> > > On Mon, May 27, 2024 at 04:23:44PM +0300, Ilpo Järvinen wrote:
> > > > diff --git a/drivers/gpio/gpio-amd8111.c b/drivers/gpio/gpio-amd8111.c
> > > > index 6f3ded619c8b..3377667a28de 100644
> > > > --- a/drivers/gpio/gpio-amd8111.c
> > > > +++ b/drivers/gpio/gpio-amd8111.c
> > > > @@ -195,8 +195,10 @@ static int __init amd_gpio_init(void)
> > > >  
> > > >  found:
> > > >  	err = pci_read_config_dword(pdev, 0x58, &gp.pmbase);
> > > > -	if (err)
> > > > +	if (err) {
> > > > +		err = pcibios_err_to_errno(err);
> > > 
> > > The patch is correct, but is the CC to stable necessary?  Is this a real
> > > concern?
> > > 
> > > Most callers don't check.  Linus Torvalds, once said something to the
> > > effect that if your PCI bus starts failing, there isn't anything the
> > > operating system can do, so checking is pointless.  The only fix is to
> > > buy new hardware.  There was a hotpluggable PCI back in the day but I
> > > don't think it exists any more.
> > 
> > I don't mind if the CC stable isn't there.
> 
> I don't mind either way.  I was hoping you were going to say it was for
> some new hotswap hardware Intel was working on.

That's not exactly the correct answer but I'm auditing all these because 
I have a sinister plan to convert the PCI accessors away from returning 
PCIBIOS_* codes and push the conversion down into real PCIBIOS interface 
under arch/x86/pci where they'd be immediately converted into errnos.

As the by-product of the audit, I see all these cases where the return
type is incorrect so I've created a fix for each where the return type 
confusion propagates.

> Smatch deletes all the failure paths from the pci_read_ functions
> because otherwise you end up with a lot of warnings that no one cares
> about.  Uninitialized variables mostly?

Please note that there's a difference between ignoring errors entirely and 
returning wrong value (type) on errors.

At this point, I've already ignored many many cases where the value type 
confusion does not propagate because of my main goal which is anyway to 
eventually get rid of having to deal with PCIBIOS_* codes in any generic 
code.

If a PCIBIOS_* return code somehow leaks into userspace where errno would 
be expected, it could confuse userspace (e.g., one case unrelated to 
module init functions I found is sysfs show function returning positive in 
case of error which has obviously different meaning from the caller's 
point of view).

In case of module init, do_module_init() checks for ret > 0 and prints 
warning + stacktrace, however, it does not attempt to correct the return 
code so I think the positive code still leaks into userspace.

-- 
 i.