linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] gpiolib: don't call sleeping functions with a spinlock taken
@ 2020-03-20  9:31 Bartosz Golaszewski
  2020-03-20 10:58 ` Geert Uytterhoeven
  2020-04-14 12:00 ` Linus Walleij
  0 siblings, 2 replies; 9+ messages in thread
From: Bartosz Golaszewski @ 2020-03-20  9:31 UTC (permalink / raw)
  To: Linus Walleij, Geert Uytterhoeven
  Cc: linux-gpio, linux-kernel, Bartosz Golaszewski

From: Bartosz Golaszewski <bgolaszewski@baylibre.com>

We must not call pinctrl_gpio_can_use_line() with the gpio_lock taken
as it takes a mutex internally. Let's move the call before taking the
spinlock and store the return value.

This isn't perfect - there's a moment between calling
pinctrl_gpio_can_use_line() and taking the spinlock where the situation
can change but it isn't a regression either: previously this part wasn't
protected at all and it only affects the information user-space is
seeing.

Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Fixes: d2ac25798208 ("gpiolib: provide a dedicated function for setting lineinfo")
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
 drivers/gpio/gpiolib.c | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 02f8b2b81199..ee20634a522c 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1154,8 +1154,19 @@ static void gpio_desc_to_lineinfo(struct gpio_desc *desc,
 				  struct gpioline_info *info)
 {
 	struct gpio_chip *chip = desc->gdev->chip;
+	bool ok_for_pinctrl;
 	unsigned long flags;
 
+	/*
+	 * This function takes a mutex so we must check this before taking
+	 * the spinlock.
+	 *
+	 * FIXME: find a non-racy way to retrieve this information. Maybe a
+	 * lock common to both frameworks?
+	 */
+	ok_for_pinctrl = pinctrl_gpio_can_use_line(
+				chip->base + info->line_offset);
+
 	spin_lock_irqsave(&gpio_lock, flags);
 
 	if (desc->name) {
@@ -1182,7 +1193,7 @@ static void gpio_desc_to_lineinfo(struct gpio_desc *desc,
 	    test_bit(FLAG_USED_AS_IRQ, &desc->flags) ||
 	    test_bit(FLAG_EXPORT, &desc->flags) ||
 	    test_bit(FLAG_SYSFS, &desc->flags) ||
-	    !pinctrl_gpio_can_use_line(chip->base + info->line_offset))
+	    !ok_for_pinctrl)
 		info->flags |= GPIOLINE_FLAG_KERNEL;
 	if (test_bit(FLAG_IS_OUT, &desc->flags))
 		info->flags |= GPIOLINE_FLAG_IS_OUT;
-- 
2.25.0


^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: [PATCH] gpiolib: don't call sleeping functions with a spinlock taken
  2020-03-20  9:31 [PATCH] gpiolib: don't call sleeping functions with a spinlock taken Bartosz Golaszewski
@ 2020-03-20 10:58 ` Geert Uytterhoeven
  2020-03-20 16:55   ` Bartosz Golaszewski
  2020-04-14 12:00 ` Linus Walleij
  1 sibling, 1 reply; 9+ messages in thread
From: Geert Uytterhoeven @ 2020-03-20 10:58 UTC (permalink / raw)
  To: Bartosz Golaszewski
  Cc: Linus Walleij, open list:GPIO SUBSYSTEM,
	Linux Kernel Mailing List, Bartosz Golaszewski

Hi Bartosz,

On Fri, Mar 20, 2020 at 10:31 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> We must not call pinctrl_gpio_can_use_line() with the gpio_lock taken
> as it takes a mutex internally. Let's move the call before taking the
> spinlock and store the return value.
>
> This isn't perfect - there's a moment between calling
> pinctrl_gpio_can_use_line() and taking the spinlock where the situation
> can change but it isn't a regression either: previously this part wasn't
> protected at all and it only affects the information user-space is
> seeing.
>
> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Fixes: d2ac25798208 ("gpiolib: provide a dedicated function for setting lineinfo")
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

Thanks for your patch!

> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -1154,8 +1154,19 @@ static void gpio_desc_to_lineinfo(struct gpio_desc *desc,
>                                   struct gpioline_info *info)
>  {
>         struct gpio_chip *chip = desc->gdev->chip;
> +       bool ok_for_pinctrl;
>         unsigned long flags;
>
> +       /*
> +        * This function takes a mutex so we must check this before taking
> +        * the spinlock.
> +        *
> +        * FIXME: find a non-racy way to retrieve this information. Maybe a
> +        * lock common to both frameworks?
> +        */
> +       ok_for_pinctrl = pinctrl_gpio_can_use_line(
> +                               chip->base + info->line_offset);

Note that this is now called unconditionally, while before it was only called
if all previous steps in the ||-pipeline failed.

> +
>         spin_lock_irqsave(&gpio_lock, flags);
>
>         if (desc->name) {
> @@ -1182,7 +1193,7 @@ static void gpio_desc_to_lineinfo(struct gpio_desc *desc,
>             test_bit(FLAG_USED_AS_IRQ, &desc->flags) ||
>             test_bit(FLAG_EXPORT, &desc->flags) ||
>             test_bit(FLAG_SYSFS, &desc->flags) ||
> -           !pinctrl_gpio_can_use_line(chip->base + info->line_offset))
> +           !ok_for_pinctrl)
>                 info->flags |= GPIOLINE_FLAG_KERNEL;
>         if (test_bit(FLAG_IS_OUT, &desc->flags))
>                 info->flags |= GPIOLINE_FLAG_IS_OUT;

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] gpiolib: don't call sleeping functions with a spinlock taken
  2020-03-20 10:58 ` Geert Uytterhoeven
@ 2020-03-20 16:55   ` Bartosz Golaszewski
  0 siblings, 0 replies; 9+ messages in thread
From: Bartosz Golaszewski @ 2020-03-20 16:55 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Linus Walleij, open list:GPIO SUBSYSTEM,
	Linux Kernel Mailing List, Bartosz Golaszewski

pt., 20 mar 2020 o 11:59 Geert Uytterhoeven <geert@linux-m68k.org> napisał(a):
>
> Hi Bartosz,
>
> On Fri, Mar 20, 2020 at 10:31 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> > From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> >
> > We must not call pinctrl_gpio_can_use_line() with the gpio_lock taken
> > as it takes a mutex internally. Let's move the call before taking the
> > spinlock and store the return value.
> >
> > This isn't perfect - there's a moment between calling
> > pinctrl_gpio_can_use_line() and taking the spinlock where the situation
> > can change but it isn't a regression either: previously this part wasn't
> > protected at all and it only affects the information user-space is
> > seeing.
> >
> > Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
> > Fixes: d2ac25798208 ("gpiolib: provide a dedicated function for setting lineinfo")
> > Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> Thanks for your patch!
>
> > --- a/drivers/gpio/gpiolib.c
> > +++ b/drivers/gpio/gpiolib.c
> > @@ -1154,8 +1154,19 @@ static void gpio_desc_to_lineinfo(struct gpio_desc *desc,
> >                                   struct gpioline_info *info)
> >  {
> >         struct gpio_chip *chip = desc->gdev->chip;
> > +       bool ok_for_pinctrl;
> >         unsigned long flags;
> >
> > +       /*
> > +        * This function takes a mutex so we must check this before taking
> > +        * the spinlock.
> > +        *
> > +        * FIXME: find a non-racy way to retrieve this information. Maybe a
> > +        * lock common to both frameworks?
> > +        */
> > +       ok_for_pinctrl = pinctrl_gpio_can_use_line(
> > +                               chip->base + info->line_offset);
>
> Note that this is now called unconditionally, while before it was only called
> if all previous steps in the ||-pipeline failed.
>

Is this a problem though? Doesn't seem so. Am I missing something?

Bart

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] gpiolib: don't call sleeping functions with a spinlock taken
  2020-03-20  9:31 [PATCH] gpiolib: don't call sleeping functions with a spinlock taken Bartosz Golaszewski
  2020-03-20 10:58 ` Geert Uytterhoeven
@ 2020-04-14 12:00 ` Linus Walleij
  2020-04-14 12:26   ` Bartosz Golaszewski
  1 sibling, 1 reply; 9+ messages in thread
From: Linus Walleij @ 2020-04-14 12:00 UTC (permalink / raw)
  To: Bartosz Golaszewski
  Cc: Geert Uytterhoeven, open list:GPIO SUBSYSTEM, linux-kernel,
	Bartosz Golaszewski

On Fri, Mar 20, 2020 at 10:31 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:

> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> We must not call pinctrl_gpio_can_use_line() with the gpio_lock taken
> as it takes a mutex internally. Let's move the call before taking the
> spinlock and store the return value.
>
> This isn't perfect - there's a moment between calling
> pinctrl_gpio_can_use_line() and taking the spinlock where the situation
> can change but it isn't a regression either: previously this part wasn't
> protected at all and it only affects the information user-space is
> seeing.
>
> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Fixes: d2ac25798208 ("gpiolib: provide a dedicated function for setting lineinfo")
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

I'm sorry that I lost track of this patch :(

Do we still need something like this or has it been fixed
by some other patches?

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] gpiolib: don't call sleeping functions with a spinlock taken
  2020-04-14 12:00 ` Linus Walleij
@ 2020-04-14 12:26   ` Bartosz Golaszewski
  2020-04-16 11:19     ` Linus Walleij
  2020-04-28 15:53     ` Andy Shevchenko
  0 siblings, 2 replies; 9+ messages in thread
From: Bartosz Golaszewski @ 2020-04-14 12:26 UTC (permalink / raw)
  To: Linus Walleij
  Cc: Bartosz Golaszewski, Geert Uytterhoeven,
	open list:GPIO SUBSYSTEM, linux-kernel

wt., 14 kwi 2020 o 14:00 Linus Walleij <linus.walleij@linaro.org> napisał(a):
>
> On Fri, Mar 20, 2020 at 10:31 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>
> > From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> >
> > We must not call pinctrl_gpio_can_use_line() with the gpio_lock taken
> > as it takes a mutex internally. Let's move the call before taking the
> > spinlock and store the return value.
> >
> > This isn't perfect - there's a moment between calling
> > pinctrl_gpio_can_use_line() and taking the spinlock where the situation
> > can change but it isn't a regression either: previously this part wasn't
> > protected at all and it only affects the information user-space is
> > seeing.
> >
> > Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
> > Fixes: d2ac25798208 ("gpiolib: provide a dedicated function for setting lineinfo")
> > Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> I'm sorry that I lost track of this patch :(
>
> Do we still need something like this or has it been fixed
> by some other patches?
>
> Yours,
> Linus Walleij

Nope, this is still an issue. Do you have a better idea than mine?

Bart

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] gpiolib: don't call sleeping functions with a spinlock taken
  2020-04-14 12:26   ` Bartosz Golaszewski
@ 2020-04-16 11:19     ` Linus Walleij
  2020-04-28 15:53     ` Andy Shevchenko
  1 sibling, 0 replies; 9+ messages in thread
From: Linus Walleij @ 2020-04-16 11:19 UTC (permalink / raw)
  To: Bartosz Golaszewski
  Cc: Bartosz Golaszewski, Geert Uytterhoeven,
	open list:GPIO SUBSYSTEM, linux-kernel

On Tue, Apr 14, 2020 at 2:27 PM Bartosz Golaszewski
<bgolaszewski@baylibre.com> wrote:
> wt., 14 kwi 2020 o 14:00 Linus Walleij <linus.walleij@linaro.org> napisał(a):
> >
> > On Fri, Mar 20, 2020 at 10:31 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> >
> > > From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> > >
> > > We must not call pinctrl_gpio_can_use_line() with the gpio_lock taken
> > > as it takes a mutex internally. Let's move the call before taking the
> > > spinlock and store the return value.
> > >
> > > This isn't perfect - there's a moment between calling
> > > pinctrl_gpio_can_use_line() and taking the spinlock where the situation
> > > can change but it isn't a regression either: previously this part wasn't
> > > protected at all and it only affects the information user-space is
> > > seeing.
> > >
> > > Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
> > > Fixes: d2ac25798208 ("gpiolib: provide a dedicated function for setting lineinfo")
> > > Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> >
> > I'm sorry that I lost track of this patch :(
> >
> > Do we still need something like this or has it been fixed
> > by some other patches?
> >
> > Yours,
> > Linus Walleij
>
> Nope, this is still an issue. Do you have a better idea than mine?

Nope, can you just queue it in your tree?
Acked-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] gpiolib: don't call sleeping functions with a spinlock taken
  2020-04-14 12:26   ` Bartosz Golaszewski
  2020-04-16 11:19     ` Linus Walleij
@ 2020-04-28 15:53     ` Andy Shevchenko
  2020-04-29  6:40       ` Bartosz Golaszewski
  1 sibling, 1 reply; 9+ messages in thread
From: Andy Shevchenko @ 2020-04-28 15:53 UTC (permalink / raw)
  To: Bartosz Golaszewski
  Cc: Linus Walleij, Bartosz Golaszewski, Geert Uytterhoeven,
	open list:GPIO SUBSYSTEM, linux-kernel

On Tue, Apr 14, 2020 at 6:35 PM Bartosz Golaszewski
<bgolaszewski@baylibre.com> wrote:
>
> wt., 14 kwi 2020 o 14:00 Linus Walleij <linus.walleij@linaro.org> napisał(a):
> >
> > On Fri, Mar 20, 2020 at 10:31 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> >
> > > From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> > >
> > > We must not call pinctrl_gpio_can_use_line() with the gpio_lock taken
> > > as it takes a mutex internally. Let's move the call before taking the
> > > spinlock and store the return value.
> > >
> > > This isn't perfect - there's a moment between calling
> > > pinctrl_gpio_can_use_line() and taking the spinlock where the situation
> > > can change but it isn't a regression either: previously this part wasn't
> > > protected at all and it only affects the information user-space is
> > > seeing.

It seems I have no original at hand, so, commenting here.

It looks like we need a mutex less function which can be used here and
in the call you are considering racy.
Note, mutex followed by spin lock is fine, other way around is not.

So, here you should have something like

mutex_lock
ok_for_gpio = ...
spin_lock
...
spin_unlock
mutex_unlock.


-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] gpiolib: don't call sleeping functions with a spinlock taken
  2020-04-28 15:53     ` Andy Shevchenko
@ 2020-04-29  6:40       ` Bartosz Golaszewski
  2020-04-29 12:37         ` Andy Shevchenko
  0 siblings, 1 reply; 9+ messages in thread
From: Bartosz Golaszewski @ 2020-04-29  6:40 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: Linus Walleij, Bartosz Golaszewski, Geert Uytterhoeven,
	open list:GPIO SUBSYSTEM, linux-kernel

wt., 28 kwi 2020 o 17:53 Andy Shevchenko <andy.shevchenko@gmail.com> napisał(a):
>
> On Tue, Apr 14, 2020 at 6:35 PM Bartosz Golaszewski
> <bgolaszewski@baylibre.com> wrote:
> >
> > wt., 14 kwi 2020 o 14:00 Linus Walleij <linus.walleij@linaro.org> napisał(a):
> > >
> > > On Fri, Mar 20, 2020 at 10:31 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> > >
> > > > From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> > > >
> > > > We must not call pinctrl_gpio_can_use_line() with the gpio_lock taken
> > > > as it takes a mutex internally. Let's move the call before taking the
> > > > spinlock and store the return value.
> > > >
> > > > This isn't perfect - there's a moment between calling
> > > > pinctrl_gpio_can_use_line() and taking the spinlock where the situation
> > > > can change but it isn't a regression either: previously this part wasn't
> > > > protected at all and it only affects the information user-space is
> > > > seeing.
>
> It seems I have no original at hand, so, commenting here.
>
> It looks like we need a mutex less function which can be used here and
> in the call you are considering racy.

The thing is this mutex is in pinctrl - we'd need to export it too so
that gpio can use it.

Bart

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] gpiolib: don't call sleeping functions with a spinlock taken
  2020-04-29  6:40       ` Bartosz Golaszewski
@ 2020-04-29 12:37         ` Andy Shevchenko
  0 siblings, 0 replies; 9+ messages in thread
From: Andy Shevchenko @ 2020-04-29 12:37 UTC (permalink / raw)
  To: Bartosz Golaszewski
  Cc: Linus Walleij, Bartosz Golaszewski, Geert Uytterhoeven,
	open list:GPIO SUBSYSTEM, linux-kernel

On Wed, Apr 29, 2020 at 9:40 AM Bartosz Golaszewski
<bgolaszewski@baylibre.com> wrote:
> wt., 28 kwi 2020 o 17:53 Andy Shevchenko <andy.shevchenko@gmail.com> napisał(a):
> > On Tue, Apr 14, 2020 at 6:35 PM Bartosz Golaszewski
> > <bgolaszewski@baylibre.com> wrote:
> > > wt., 14 kwi 2020 o 14:00 Linus Walleij <linus.walleij@linaro.org> napisał(a):
> > > > On Fri, Mar 20, 2020 at 10:31 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:

...

> > It looks like we need a mutex less function which can be used here and
> > in the call you are considering racy.
>
> The thing is this mutex is in pinctrl - we'd need to export it too so
> that gpio can use it.

Oh, I see now. So, something like

pinctrl_ext_operation_begin()
....
pinctrl_ext_operation_end()

perhaps.

-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2020-04-29 12:37 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-20  9:31 [PATCH] gpiolib: don't call sleeping functions with a spinlock taken Bartosz Golaszewski
2020-03-20 10:58 ` Geert Uytterhoeven
2020-03-20 16:55   ` Bartosz Golaszewski
2020-04-14 12:00 ` Linus Walleij
2020-04-14 12:26   ` Bartosz Golaszewski
2020-04-16 11:19     ` Linus Walleij
2020-04-28 15:53     ` Andy Shevchenko
2020-04-29  6:40       ` Bartosz Golaszewski
2020-04-29 12:37         ` Andy Shevchenko

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).