On Fri, Sep 25, 2020 at 06:13:37PM -0600, Shuah Khan wrote: > On 9/25/20 5:52 PM, Kees Cook wrote: > > On Fri, Sep 25, 2020 at 05:47:14PM -0600, Shuah Khan wrote: > > > -- Addressed Kees's comments: > > > 1. Non-atomic counters renamed to counter_simple32 and counter_simple64 > > > to clearly indicate size. > > > 2. Added warning for counter_simple* usage and it should be used only > > > when there is no need for atomicity. > > > 3. Renamed counter_atomic to counter_atomic32 to clearly indicate size. > > > 4. Renamed counter_atomic_long to counter_atomic64 and it now uses > > > atomic64_t ops and indicates size. > > > 5. Test updated for the API renames. > > > 6. Added helper functions for test results printing > > > 7. Verified that the test module compiles in kunit env. and test > > > module can be loaded to run the test. > > > > Thanks for all of this! > > > > > 8. Updated Documentation to reflect the intent to make the API > > > restricted so it can never be used to guard object lifetimes > > > and state management. I left _return ops for now, inc_return > > > is necessary for now as per the discussion we had on this topic. > > > > I still *really* do not want dec_return() to exist. That is asking for > > trouble. I'd prefer inc_return() not exist either, but I can live with > > it. ;) > > > > Thanks. I am equally concerned about adding anything that can be used to > guard object lifetimes. So I will make sure this set won't expand and > plan to remove dec_return() if we don't find any usages. I would like it much stronger than "if". dec_return() needs to be just dec() and read(). It will not be less efficient (since they're both inlines), but it _will_ create a case where the atomicity cannot be used for ref counting. My point is that anything that _requires_ dec_return() (or, frankly, inc_return()) is _not_ "just" a statistical counter. It may not be a refcounter, but it relies on the inc/dec atomicity for some reason beyond counting in once place and reporting it in another. -- Kees Cook
