From: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
To: Dan Carpenter <dan.carpenter@linaro.org>
Cc: Linus Walleij <linus.walleij@linaro.org>,
Bartosz Golaszewski <brgl@bgdev.pl>,
Dmitry Baryshkov <dbaryshkov@gmail.com>,
linux-gpio@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
stable@vger.kernel.org
Subject: Re: [PATCH 1/2] gpio: amd8111: Convert PCIBIOS_* return codes to errnos
Date: Mon, 27 May 2024 17:57:02 +0300 (EEST) [thread overview]
Message-ID: <8ca1b7a8-5abb-e7b7-2e08-ec8c8edccdcb@linux.intel.com> (raw)
In-Reply-To: <50e1c6a7-f583-4b5b-997b-2e505b3df0ec@moroto.mountain>
[-- Attachment #1: Type: text/plain, Size: 2884 bytes --]
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.
next prev parent reply other threads:[~2024-05-27 14:57 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-27 13:23 [PATCH 1/2] gpio: amd8111: Convert PCIBIOS_* return codes to errnos Ilpo Järvinen
2024-05-27 13:23 ` [PATCH 2/2] gpio: rdc321x: " Ilpo Järvinen
2024-05-27 14:02 ` [PATCH 1/2] gpio: amd8111: " Dan Carpenter
2024-05-27 14:11 ` Ilpo Järvinen
2024-05-27 14:26 ` Dan Carpenter
2024-05-27 14:57 ` Ilpo Järvinen [this message]
2024-05-30 9:30 ` Andy Shevchenko
2024-05-30 9:21 ` Bartosz Golaszewski
2024-05-30 9:22 ` Bartosz Golaszewski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8ca1b7a8-5abb-e7b7-2e08-ec8c8edccdcb@linux.intel.com \
--to=ilpo.jarvinen@linux.intel.com \
--cc=brgl@bgdev.pl \
--cc=dan.carpenter@linaro.org \
--cc=dbaryshkov@gmail.com \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).