linux-kernel - Re: [PATCH v9 08/20] gpiolib: cdev: support GPIO_V2_GET_LINEINFO_IOCTL and GPIO_V2_GET_LINEINFO_WATCH

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

Message-ID: <20200924094813.GC20188@sol>
Date:   Thu, 24 Sep 2020 17:48:13 +0800
From:   Kent Gibson <warthog618@...il.com>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Arnd Bergmann <arnd@...db.de>
Subject: Re: [PATCH v9 08/20] gpiolib: cdev: support
 GPIO_V2_GET_LINEINFO_IOCTL and GPIO_V2_GET_LINEINFO_WATCH_IOCTL

On Thu, Sep 24, 2020 at 11:39:03AM +0300, Andy Shevchenko wrote:
> On Thu, Sep 24, 2020 at 5:39 AM Kent Gibson <warthog618@...il.com> wrote:
> > 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@...il.com> wrote:
> 
> ...
> 

[snip]
> 
> > > > +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.
> 
> Then what's the point to read back?..
> 
> > > 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?
> 
> CPU0:                CPU1:
>  xchg()               ...
>  ...                      xchg()
>  ...                      read() -> OK
> read() ->NOK
> 

Lets say CPU0 is setting 1 and CPU1 setting 2, and assuming the xchg()
completes...
Your case is not possible - CPU1 would see the value 1 set by CPU0 in the
read() and so NOK.  Its xchg() would fail as it compares against 0
and that also sees the 1 and so fails.

What am I missing?

> > 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.
> 
> So, that's basically what you need when using _old_ value.
> 
> 0 means you were first, right?
> Anything else you simply compare and bail out if it's not the same as
> what has been asked.
> 

Could you provide a complete implementation that behaves as I expect,
rather than snippets and verbage?

> >
> > > 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.
> 
> Yes, I guess documentation is what is eagerly needed here.
> 

No problem.

Cheers,
Kent.