linux-kernel - Re: [PATCH v2 10/10] gpiolib: remove gpiochip_is

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMRc=McpYK9vLA65zdoteUa72_cpwzmv3X_pZt5purocDYBJnw@mail.gmail.com>
Date:   Thu, 30 Nov 2023 18:46:20 +0100
From:   Bartosz Golaszewski <brgl@...ev.pl>
To:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc:     Linus Walleij <linus.walleij@...aro.org>,
        linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org,
        Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
Subject: Re: [PATCH v2 10/10] gpiolib: remove gpiochip_is_requested()

On Thu, Nov 30, 2023 at 5:46 PM Andy Shevchenko
<andriy.shevchenko@...ux.intel.com> wrote:
>
> On Thu, Nov 30, 2023 at 02:46:30PM +0100, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
> >
> > We have no external users of gpiochip_is_requested(). Let's remove it
> > and replace its internal calls with direct testing of the REQUESTED flag.
>
> ...
>
> > -     cpy = kstrdup(label, GFP_KERNEL);
> > -     if (!cpy)
> > -             return ERR_PTR(-ENOMEM);
> > +     scoped_guard(spinlock_irqsave, &gpio_lock) {
> > +             if (!test_bit(FLAG_REQUESTED, &desc->flags))
> > +                     return NULL;
>
> > +             cpy = kstrdup(desc->label, GFP_KERNEL);
> > +             if (!cpy)
> > +                     return ERR_PTR(-ENOMEM);
>
> You just introduced these lines earlier in the series, and here you moved
> them again. With guard() instead it may be kept in a better shape.
>

I wanted to limit the critical section to a minimum hence scoped
variant. And this will go away as soon as we have a desc lock so it's
temporary anyway. What matters to me is how the code looks when
sending it to Torvalds. On the off chance that we don't get the
locking rework merged in time for v6.8, I want this to at least be
under the existing lock.

Bart

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