linux-kernel - Re: [PATCH] gpio: wcove: remove platform_set

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] [day] [month] [year] [list]

Date:   Thu, 8 Jul 2021 10:03:12 +0300
From:   Alexandru Ardelean <aardelean@...iqon.com>
To:     Andy Shevchenko <andriy.shevchenko@...el.com>
Cc:     linux-gpio <linux-gpio@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        sathyanarayanan.kuppuswamy@...ux.intel.com, andy@...nel.org
Subject: Re: [PATCH] gpio: wcove: remove platform_set_drvdata() + cleanup probe

On Wed, 7 Jul 2021 at 17:09, Andy Shevchenko
<andriy.shevchenko@...el.com> wrote:
>
> On Wed, Jul 07, 2021 at 04:52:26PM +0300, Alexandru Ardelean wrote:
> > The platform_set_drvdata() call is only useful if we need to retrieve back
> > the private information.
> > Since the driver doesn't do that, it's not useful to have it.
>
> This is fine.
>
> > This change also changes the probe order a bit, moving the
> > devm_gpiochip_add_data() as the last call. This means that when the
> > gpiochip is registered [and available to consumers], it should be
> > initialized.
> >
> > It's still possible that the devm_gpiochip_add_data() call could fail,
> > leaving the chip in a partially initialized state, but that was possible
> > even before this change; it was just some other partially initialized
> > state.
>
> ...
>
> >       /* Enable GPIO0 interrupts */
>
> ^^^^^
>
> > +     return devm_gpiochip_add_data(dev, &wg->chip, wg);
>
> This is dangerous change. How did you test it?
>
> The handler now can be called before chip and actual handling code is
> registered. It means at least two possible (bad) scenarios:
>  1) the handler may dereference dangling or NULL pointer;
>  2) the IRQ may be level interrupt and we may got 100000 IRQs and
>     IRQ core will disable it leaving device completely unfunctional.


Makes sense.
Let's drop this :)


>
> --
> With Best Regards,
> Andy Shevchenko
>
>