> On Mon, Oct 23, 2017 at 02:09:44PM +0300, Elena Reshetova wrote:
> > Currently arch. independent implementation of refcount_t in
> > lib/refcount.c provides weak memory ordering guarantees
> > compare to its analog atomic_t implementations.
> > While it should not be a problem for most of the actual
> > cases of refcounters, it is more understandable for everyone
> > (and more error-prone for future users) to provide exactly
> > same memory ordering guarantees as atomics.
> >
> > If speed is of a concern, then either more efficient arch.
> > dependent refcount_t implementation should be used or if there
> > are enough users in the future we might need to provide both
> > strict and relaxed refcount_t APIs.
> >
> > Suggested-by: Kees Cook <[email protected]>
>
> NAK
Could we possibly have a bit more elaborate discussion on this?
Or alternatively, what then should be the correct way for a certain variable (that behaves like
a standard refcounter) to check if the relaxed memory ordering is ok?
This is what Thomas was asking me to do for core kernel conversions and this
is what I don't know how to do correctly. Also, I got exactly the same question
from xfs maintainer, so if we provide an API that we hope will be used correctly in
the future, we should have a way for people to verify it.
Maybe it is just me, but I would think that having a way to verify that your code
is ok with this refcounter-specific relaxed memory ordering applies to any memory ordering
requirements, refcounters are just a subset with certain properties, so is then
the full answer is to figure out how to verify any memory ordering requirement
of your code?
We can also document this logic in more docs or even maybe try to create a better
documentation for current memory ordering bits since it is not the most easiest read
at the moment. Otherwise this might be just bad enough reason for many people to
avoid refcount_t type if it is just easier to tell "let's take just old atomic, we knew it
somehow worked before"....
Best Regards,
Elena.
From 1582054140498640955@xxx Mon Oct 23 13:13:20 +0000 2017
X-GM-THRID: 1582046402032606032
X-Gmail-Labels: Inbox,Category Forums