Re: [PATCH 00/11] Introduce Simple atomic and non-atomic counters

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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








[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux