Re: [PATCH v9 08/20] gpiolib: cdev: support GPIO_V2_GET_LINEINFO_IOCTL and GPIO_V2_GET_LINEINFO_WATCH_IOCTL

[Andy Shevchenko <andy.shevchenko@xxxxxxxxx>]

On Thu, Sep 24, 2020 at 12:48 PM Kent Gibson <warthog618@xxxxxxxxx> wrote:
> 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@xxxxxxxxx> 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@xxxxxxxxx> wrote:

...

> > > > > +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?

Barriers? That's what documentation says about xchg().
https://stackoverflow.com/q/20950603/2511795

> > > 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?

if (atomic_cmpxchg(&cdata..., version) == 0)
 return 0; // we were first!
return -EPERM; // somebody has changed the version before us!

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

-- 
With Best Regards,
Andy Shevchenko