Re: [PATCH] gpio: Do not trigger WARN() with sysfs gpio export/unexport

[Damien Le Moal <Damien.LeMoal@xxxxxxx>]

On Fri, 2020-11-06 at 10:27 +0100, Bartosz Golaszewski wrote:
> On Wed, Nov 4, 2020 at 12:53 PM Damien Le Moal <damien.lemoal@xxxxxxx> wrote:
> > 
> > If a user tries to export or unexport an invalid gpio (e.g. gpio number
> > > = ARCH_NR_GPIOS), gpio_to_desc() will trigger a register dump through a
> > WARN() call. Avoid this rather scary error message by first checking the
> > validity of the gpio number before calling gpio_to_desc() in
> > export_store() and unexport_store(). The user gets a normal error
> > message to signal his/her error without any possible confusion with a
> > kernel bug.
> > 
> > Signed-off-by: Damien Le Moal <damien.lemoal@xxxxxxx>
> > ---
> >  drivers/gpio/gpiolib-sysfs.c | 11 +++++++----
> >  1 file changed, 7 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpio/gpiolib-sysfs.c b/drivers/gpio/gpiolib-sysfs.c
> > index 728f6c687182..b6fd0d82757a 100644
> > --- a/drivers/gpio/gpiolib-sysfs.c
> > +++ b/drivers/gpio/gpiolib-sysfs.c
> > @@ -3,6 +3,7 @@
> >  #include <linux/mutex.h>
> >  #include <linux/device.h>
> >  #include <linux/sysfs.h>
> > +#include <linux/gpio.h>
> >  #include <linux/gpio/consumer.h>
> >  #include <linux/gpio/driver.h>
> >  #include <linux/interrupt.h>
> > @@ -456,14 +457,15 @@ static ssize_t export_store(struct class *class,
> >                                 const char *buf, size_t len)
> >  {
> >         long                    gpio;
> > -       struct gpio_desc        *desc;
> > +       struct gpio_desc        *desc = NULL;
> >         int                     status;
> > 
> >         status = kstrtol(buf, 0, &gpio);
> >         if (status < 0)
> >                 goto done;
> > 
> > -       desc = gpio_to_desc(gpio);
> > +       if (gpio_is_valid(gpio))
> > +               desc = gpio_to_desc(gpio);
> >         /* reject invalid GPIOs */
> >         if (!desc) {
> >                 pr_warn("%s: invalid GPIO %ld\n", __func__, gpio);
> > @@ -503,14 +505,15 @@ static ssize_t unexport_store(struct class *class,
> >                                 const char *buf, size_t len)
> >  {
> >         long                    gpio;
> > -       struct gpio_desc        *desc;
> > +       struct gpio_desc        *desc = NULL;
> >         int                     status;
> > 
> >         status = kstrtol(buf, 0, &gpio);
> >         if (status < 0)
> >                 goto done;
> > 
> > -       desc = gpio_to_desc(gpio);
> > +       if (gpio_is_valid(gpio))
> > +               desc = gpio_to_desc(gpio);
> >         /* reject bogus commands (gpio_unexport ignores them) */
> >         if (!desc) {
> >                 pr_warn("%s: invalid GPIO %ld\n", __func__, gpio);
> > --
> > 2.28.0
> > 
> 
> How about we change that to an unconditional WARN() everytime the user
> tries to export a GPIO over sysfs so that people switch over to the
> character device?
> 
> I'm joking a bit but I think it's time to start discouraging people
> from using sysfs and a warning may be a good start.

I am all for a good pr_warn() to tell the user "you screwed up". Adding another
warning along the lines of pr_warn("Please prefer using /dev/gpioXX instead of
sysfs\n") is probably an option too.

But a WARN_ON() with its register & stack dump is too much in my opinion. When
I hit that, I thought "Cr.p, another bug..." and 30s investigation made me
realize that I did an "echo 512 > /sys/class/gpio/export" to export gpio #7 of
my board controller which has a base of 504. The typical off-by-one brain bug
:)

Hence the patch I sent. It keeps the pr_warn for user mistakes like I did, AND
keeps the more serious WARN_ON() for internal bad usage of gpio numbers.

As for the sysfs interface, I would argue that it is already optional through
CONFIG_GPIO_SYSFS. It may not be the best interface for regular end users to
manipulate gpios, but it is definitely super useful for developers to do quick
tests of their setup/drivers (which is what I did for my work with the Kendryte
K210 RISC-V SoC support). We may want to enforce a policy of having arch
defconfigs not enabling this option by default, and recommend that distros
disable it if needed too. But such discussion is I think beyond the point of
this patch.

> 
> Bartosz

-- 
Damien Le Moal
Western Digital