linux-gpio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kent Gibson <warthog618@gmail.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	Arnd Bergmann <arnd@arndb.de>
Subject: Re: [PATCH v9 08/20] gpiolib: cdev: support GPIO_V2_GET_LINEINFO_IOCTL and GPIO_V2_GET_LINEINFO_WATCH_IOCTL
Date: Thu, 24 Sep 2020 10:39:14 +0800	[thread overview]
Message-ID: <20200924023914.GA11575@sol> (raw)
In-Reply-To: <CAHp75Vc05P4-X_ZC6k-EWdDCAXOgPgAJhm4RxF3izvk=vW+X+g@mail.gmail.com>

On Wed, Sep 23, 2020 at 06:41:45PM +0300, Andy Shevchenko wrote:
> On Tue, Sep 22, 2020 at 5:35 AM Kent Gibson <warthog618@gmail.com> wrote:
> >
> > Add support for GPIO_V2_GET_LINEINFO_IOCTL and
> > GPIO_V2_GET_LINEINFO_WATCH_IOCTL.
> >

[snip]

> >
> > +static void gpio_v2_line_info_to_v1(struct gpio_v2_line_info *info_v2,
> > +                                   struct gpioline_info *info_v1)
> > +{
> > +       u64 flagsv2 = info_v2->flags;
> > +
> > +       memcpy(info_v1->name, info_v2->name, sizeof(info_v1->name));
> 
> > +       memcpy(info_v1->consumer, info_v2->consumer,
> > +              sizeof(info_v1->consumer));
> 
> One line?
> 

It can be now the line length limit has been raised - it just breaks the
old 80 character limit.

[snip]
> >
> > +#ifdef CONFIG_GPIO_CDEV_V1
> > +static int lineinfo_ensure_abi_version(struct gpio_chardev_data *cdata,
> > +                                      unsigned int version)
> > +{
> 
> > +       int abiv = atomic_read(&cdata->watch_abi_version);
> > +
> > +       if (abiv == 0) {
> 
> > +               atomic_cmpxchg(&cdata->watch_abi_version, 0, version);
> > +               abiv = atomic_read(&cdata->watch_abi_version);
> 
> atomic_cmpxchng() returns a value.

Yep, it returns the old value - which we don't care about - see below.

> Also there are no barriers here...
> 

No barriers required - the atomic_cmpxchg() is sufficient.

> > +       }
> > +       if (abiv != version)
> > +               return -EPERM;
> 
> I'm not sure I understand why this is atomic.
> 

The algorithm requires some level of protection and atomic is
sufficient.

> Also this seems to be racy if cdata changed in background.
> 

Can you provide a case?

The atomic_cmpxchg() ensures cdata->watch_abi_version is only set 
once - first in wins.  The atomic_read() is so we can check that
the set version matches what the caller wants.
Note that multiple callers may request the same version - and all
should succeed.

> Shouldn't be rather
> 
> if (atomic_cmpxchg() == 0) {
>   if (atomic_read() != version)
>     return ...;
> }
> 

My algorithm allows for multiple callers requesting the same version
to all succeed.  Yours would fail the first conditional for all but
the first, and you haven't provided an else for that case...

... but it would probably look the same so the conditional is pointless,
or it would reject the request - which would be wrong.

> But here is still the question: why do you expect the version to be
> changed on background? And what about barriers?
> 

While it is unlikely that userspace will be attempting to use both ABI
versions simultaneously on the same chip request, it is a possiblity and
so needs to be protected against. And better to have the watch request
fail than the read fail or worse - return the wrong struct version.

The atomic_cmpxchg() is sufficient for this algorithm - no barriers
required.  It could also be written with a spinlock but I was trying to
avoid locks unless they were absolutely necessary.  A spinlock version
may arguably be more readable, but it would certainly be more verbose,
larger and slower.

I'm happy to add some documentation to the function if that would help.

> > +       return 0;
> > +}
> > +#endif
> > +
> > +static int lineinfo_get(struct gpio_chardev_data *cdev, void __user *ip,
> > +                       bool watch)
> > +{
> > +       struct gpio_desc *desc;
> > +       struct gpio_v2_line_info lineinfo;
> > +
> > +       if (copy_from_user(&lineinfo, ip, sizeof(lineinfo)))
> > +               return -EFAULT;
> > +
> > +       if (memchr_inv(lineinfo.padding, 0, sizeof(lineinfo.padding)))
> > +               return -EINVAL;
> > +
> > +       desc = gpiochip_get_desc(cdev->gdev->chip, lineinfo.offset);
> > +       if (IS_ERR(desc))
> > +               return PTR_ERR(desc);
> > +
> > +       if (watch) {
> > +#ifdef CONFIG_GPIO_CDEV_V1
> 
> > +               if (lineinfo_ensure_abi_version(cdev, 2))
> > +                       return -EPERM;
> 
> Can't you propagate error code from the function?
> 

You mean:
+               ret = lineinfo_ensure_abi_version(cdev, 2)
+               if (ret)
+                       return ret;

That seems more verbose and less clear.  And I'd need to conditionally
declare a ret - as this test is compiled out if CDEV_V1 is not defined.

I did flip-flop on what lineinfo_ensure_abi_version() should return -
either a bool or an error code.

If a bool then the code would include the dreaded negative conditional
;-(:

+               if (!lineinfo_is_abi_version(cdev, 2))
+                       return -EPERM;

so I eventually settled for the error code.  But I'm on the fence on
this one and happy to change it if you think the bool form is clearer.

Cheers,
Kent.

  reply	other threads:[~2020-09-24  2:39 UTC|newest]

Thread overview: 77+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-22  2:31 [PATCH v9 00/20] gpio: cdev: add uAPI v2 Kent Gibson
2020-09-22  2:31 ` [PATCH v9 01/20] gpiolib: cdev: gpio_desc_to_lineinfo() should set info offset Kent Gibson
2020-09-22  2:31 ` [PATCH v9 02/20] gpiolib: cdev: replace strncpy() with strscpy() Kent Gibson
2020-09-22  2:31 ` [PATCH v9 03/20] gpio: uapi: define GPIO_MAX_NAME_SIZE for array sizes Kent Gibson
2020-09-22  2:31 ` [PATCH v9 04/20] gpio: uapi: define uAPI v2 Kent Gibson
2020-09-22  7:41   ` Arnd Bergmann
2020-09-22  9:50     ` Bartosz Golaszewski
2020-09-22 10:07       ` Kent Gibson
2020-09-28 13:42       ` strace decoding for GPIO uAPI Kent Gibson
2020-09-29 13:20         ` Bartosz Golaszewski
2020-09-29 15:04           ` Kent Gibson
2020-09-29 16:19           ` Andy Shevchenko
2020-09-23 10:04   ` [PATCH v9 04/20] gpio: uapi: define uAPI v2 Andy Shevchenko
2020-09-23 10:30     ` Kent Gibson
2020-09-23 11:16       ` Andy Shevchenko
2020-09-23 12:18         ` Arnd Bergmann
2020-09-23 15:15           ` Andy Shevchenko
2020-09-22  2:31 ` [PATCH v9 05/20] gpiolib: make cdev a build option Kent Gibson
2020-09-22  2:31 ` [PATCH v9 06/20] gpiolib: add build option for CDEV v1 ABI Kent Gibson
2020-09-22  2:31 ` [PATCH v9 07/20] gpiolib: cdev: support GPIO_V2_GET_LINE_IOCTL and GPIO_V2_LINE_GET_VALUES_IOCTL Kent Gibson
2020-09-23 11:11   ` Andy Shevchenko
2020-09-24  8:09     ` Kent Gibson
2020-09-25 10:06       ` Andy Shevchenko
2020-09-26  9:16         ` Kent Gibson
2020-09-27  9:00           ` Andy Shevchenko
2020-09-27 12:39             ` Kent Gibson
2020-09-24 14:29     ` Bartosz Golaszewski
2020-09-22  2:31 ` [PATCH v9 08/20] gpiolib: cdev: support GPIO_V2_GET_LINEINFO_IOCTL and GPIO_V2_GET_LINEINFO_WATCH_IOCTL Kent Gibson
2020-09-23 15:41   ` Andy Shevchenko
2020-09-24  2:39     ` Kent Gibson [this message]
2020-09-24  8:39       ` Andy Shevchenko
2020-09-24  9:48         ` Kent Gibson
2020-09-25 10:12           ` Andy Shevchenko
2020-09-25 11:56             ` Kent Gibson
2020-09-25 14:43               ` Andy Shevchenko
2020-09-25  5:32     ` Kent Gibson
2020-09-22  2:31 ` [PATCH v9 09/20] gpiolib: cdev: support edge detection for uAPI v2 Kent Gibson
2020-09-23 15:47   ` Andy Shevchenko
2020-09-24  3:07     ` Kent Gibson
2020-09-25  9:35       ` Andy Shevchenko
2020-09-25 12:26         ` Kent Gibson
2020-09-25 14:48           ` Andy Shevchenko
2020-09-22  2:31 ` [PATCH v9 10/20] gpiolib: cdev: support GPIO_V2_LINE_SET_CONFIG_IOCTL Kent Gibson
2020-09-23 16:14   ` Andy Shevchenko
2020-09-23 16:15     ` Andy Shevchenko
2020-09-24  3:24       ` Kent Gibson
2020-09-24  8:26         ` Andy Shevchenko
2020-09-24  9:26           ` Kent Gibson
2020-09-25  9:49             ` Andy Shevchenko
2020-09-22  2:31 ` [PATCH v9 11/20] gpiolib: cdev: support GPIO_V2_LINE_SET_VALUES_IOCTL Kent Gibson
2020-09-23 16:18   ` Andy Shevchenko
2020-09-24  7:32     ` Kent Gibson
2020-09-24  8:21       ` Andy Shevchenko
2020-09-24  9:08         ` Kent Gibson
2020-09-24 12:46       ` Kent Gibson
2020-09-25  9:57         ` Andy Shevchenko
2020-09-25 12:16           ` Kent Gibson
2020-09-22  2:31 ` [PATCH v9 12/20] gpiolib: cdev: support setting debounce Kent Gibson
2020-09-23 16:27   ` Andy Shevchenko
2020-09-24  7:48     ` Kent Gibson
2020-09-25  9:43       ` Andy Shevchenko
2020-09-22  2:31 ` [PATCH v9 13/20] gpio: uapi: document uAPI v1 as deprecated Kent Gibson
2020-09-22  7:49   ` Arnd Bergmann
2020-09-22  8:11     ` Andy Shevchenko
2020-09-22  9:05     ` Kent Gibson
2020-09-22  2:31 ` [PATCH v9 14/20] tools: gpio: port lsgpio to v2 uAPI Kent Gibson
2020-09-22  2:31 ` [PATCH v9 15/20] tools: gpio: port gpio-watch " Kent Gibson
2020-09-22  2:31 ` [PATCH v9 16/20] tools: gpio: rename nlines to num_lines Kent Gibson
2020-09-22  2:31 ` [PATCH v9 17/20] tools: gpio: port gpio-hammer to v2 uAPI Kent Gibson
2020-09-23 16:30   ` Andy Shevchenko
2020-09-24  7:50     ` Kent Gibson
2020-09-22  2:31 ` [PATCH v9 18/20] tools: gpio: port gpio-event-mon " Kent Gibson
2020-09-22  2:31 ` [PATCH v9 19/20] tools: gpio: add multi-line monitoring to gpio-event-mon Kent Gibson
2020-09-22  2:31 ` [PATCH v9 20/20] tools: gpio: add debounce support " Kent Gibson
2020-09-23 16:35 ` [PATCH v9 00/20] gpio: cdev: add uAPI v2 Andy Shevchenko
2020-09-24  8:00   ` Kent Gibson
2020-09-25  9:44     ` Andy Shevchenko

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=20200924023914.GA11575@sol \
    --to=warthog618@gmail.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=arnd@arndb.de \
    --cc=bgolaszewski@baylibre.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@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).