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