From: Shuah Khan <skhan@linuxfoundation.org> To: Kees Cook <keescook@chromium.org> Cc: corbet@lwn.net, gregkh@linuxfoundation.org, shuah@kernel.org, rafael@kernel.org, johannes@sipsolutions.net, lenb@kernel.org, james.morse@arm.com, tony.luck@intel.com, bp@alien8.de, arve@android.com, tkjos@android.com, maco@android.com, joel@joelfernandes.org, christian@brauner.io, hridya@google.com, surenb@google.com, minyard@acm.org, arnd@arndb.de, mchehab@kernel.org, rric@kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-acpi@vger.kernel.org, devel@driverdev.osuosl.org, openipmi-developer@lists.sourceforge.net, linux-edac@vger.kernel.org, Shuah Khan <skhan@linuxfoundation.org> Subject: Re: [PATCH 00/11] Introduce Simple atomic and non-atomic counters Date: Mon, 28 Sep 2020 16:52:41 -0600 [thread overview] Message-ID: <31f28240-a3f1-e730-0b10-024125b1d2ab@linuxfoundation.org> (raw) In-Reply-To: <202009260930.9252966D@keescook> 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
WARNING: multiple messages have this Message-ID (diff)
From: Shuah Khan <skhan@linuxfoundation.org> To: Kees Cook <keescook@chromium.org> Cc: rafael@kernel.org, linux-kselftest@vger.kernel.org, joel@joelfernandes.org, rric@kernel.org, shuah@kernel.org, devel@driverdev.osuosl.org, minyard@acm.org, corbet@lwn.net, surenb@google.com, linux-doc@vger.kernel.org, linux-acpi@vger.kernel.org, lenb@kernel.org, tkjos@android.com, arnd@arndb.de, bp@alien8.de, Shuah Khan <skhan@linuxfoundation.org>, openipmi-developer@lists.sourceforge.net, mchehab@kernel.org, maco@android.com, christian@brauner.io, linux-edac@vger.kernel.org, tony.luck@intel.com, gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, arve@android.com, james.morse@arm.com, hridya@google.com, johannes@sipsolutions.net Subject: Re: [PATCH 00/11] Introduce Simple atomic and non-atomic counters Date: Mon, 28 Sep 2020 16:52:41 -0600 [thread overview] Message-ID: <31f28240-a3f1-e730-0b10-024125b1d2ab@linuxfoundation.org> (raw) In-Reply-To: <202009260930.9252966D@keescook> 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 _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
next prev parent reply other threads:[~2020-09-28 23:29 UTC|newest] Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-09-25 23:47 [PATCH 00/11] Introduce Simple atomic and non-atomic counters Shuah Khan 2020-09-25 23:47 ` Shuah Khan 2020-09-25 23:47 ` [PATCH 01/11] counters: Introduce counter_simple* and counter_atomic* counters Shuah Khan 2020-09-25 23:47 ` [PATCH 02/11] selftests:lib:test_counters: add new test for counters Shuah Khan 2020-09-25 23:47 ` [PATCH 03/11] drivers/base: convert deferred_trigger_count and probe_count to counter_atomic32 Shuah Khan 2020-09-25 23:47 ` [PATCH 04/11] drivers/base/devcoredump: convert devcd_count " Shuah Khan 2020-09-25 23:47 ` [PATCH 05/11] drivers/acpi: convert seqno counter_atomic32 Shuah Khan 2020-09-25 23:47 ` [PATCH 06/11] drivers/acpi/apei: " Shuah Khan 2020-09-25 23:47 ` [PATCH 07/11] drivers/android/binder: convert stats, transaction_log to counter_atomic32 Shuah Khan 2020-09-25 23:47 ` Shuah Khan 2020-09-27 23:39 ` Joel Fernandes 2020-09-27 23:39 ` Joel Fernandes 2020-09-25 23:47 ` [PATCH 08/11] drivers/base/test/test_async_driver_probe: convert to use counter_atomic32 Shuah Khan 2020-09-25 23:47 ` [PATCH 09/11] drivers/char/ipmi: convert stats " Shuah Khan 2020-09-26 0:15 ` Corey Minyard 2020-09-26 2:05 ` Shuah Khan 2020-09-25 23:47 ` [PATCH 10/11] drivers/misc/vmw_vmci: convert num guest devices counter to counter_atomic32 Shuah Khan 2020-09-25 23:47 ` [PATCH 11/11] drivers/edac: convert pci counters " Shuah Khan 2020-09-28 12:05 ` Borislav Petkov 2020-09-25 23:52 ` [PATCH 00/11] Introduce Simple atomic and non-atomic counters Kees Cook 2020-09-25 23:52 ` Kees Cook 2020-09-26 0:13 ` Shuah Khan 2020-09-26 0:13 ` Shuah Khan 2020-09-26 16:33 ` Kees Cook 2020-09-26 16:33 ` Kees Cook 2020-09-28 22:52 ` Shuah Khan [this message] 2020-09-28 22:52 ` Shuah Khan 2020-09-26 16:22 ` Kees Cook 2020-09-26 16:22 ` Kees Cook 2020-09-28 22:42 ` Shuah Khan 2020-09-28 22:42 ` Shuah Khan 2020-09-26 16:29 ` Kees Cook 2020-09-26 16:29 ` Kees Cook 2020-09-28 22:41 ` Shuah Khan 2020-09-28 22:41 ` Shuah Khan 2020-09-28 23:13 ` Kees Cook 2020-09-28 23:13 ` Kees Cook 2020-10-06 15:21 ` Shuah Khan 2020-10-06 15:21 ` Shuah Khan 2020-09-27 23:35 ` Joel Fernandes 2020-09-27 23:35 ` Joel Fernandes 2020-09-28 20:34 ` Kees Cook 2020-09-28 20:34 ` Kees Cook 2020-09-28 21:17 ` Joel Fernandes 2020-09-28 21:17 ` Joel Fernandes 2020-09-28 23:01 ` Shuah Khan 2020-09-28 23:01 ` Shuah Khan
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=31f28240-a3f1-e730-0b10-024125b1d2ab@linuxfoundation.org \ --to=skhan@linuxfoundation.org \ --cc=arnd@arndb.de \ --cc=arve@android.com \ --cc=bp@alien8.de \ --cc=christian@brauner.io \ --cc=corbet@lwn.net \ --cc=devel@driverdev.osuosl.org \ --cc=gregkh@linuxfoundation.org \ --cc=hridya@google.com \ --cc=james.morse@arm.com \ --cc=joel@joelfernandes.org \ --cc=johannes@sipsolutions.net \ --cc=keescook@chromium.org \ --cc=lenb@kernel.org \ --cc=linux-acpi@vger.kernel.org \ --cc=linux-doc@vger.kernel.org \ --cc=linux-edac@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-kselftest@vger.kernel.org \ --cc=maco@android.com \ --cc=mchehab@kernel.org \ --cc=minyard@acm.org \ --cc=openipmi-developer@lists.sourceforge.net \ --cc=rafael@kernel.org \ --cc=rric@kernel.org \ --cc=shuah@kernel.org \ --cc=surenb@google.com \ --cc=tkjos@android.com \ --cc=tony.luck@intel.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.