Messages in this thread | | | Subject | Re: [PATCH 00/11] Introduce Simple atomic and non-atomic counters | From | Shuah Khan <> | Date | Mon, 28 Sep 2020 16:52:41 -0600 |
| |
On 9/26/20 10:33 AM, Kees Cook wrote: > 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. ;) >>> >>
I didn't read this correctly the first time around.
>> 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. >
I am not thinking about efficiency rather two calls instead of one if an decrement needs to followed by return. In any case, I agree with you that there is no need to add dec_return now without any use-cases.
I will update the patch series to remove it.
thanks, -- Shuah
| |