From: Kees Cook <keescook@chromium.org>
To: Shuah Khan <skhan@linuxfoundation.org>
Cc: corbet@lwn.net, gregkh@linuxfoundation.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 01/11] counters: Introduce counter and counter_atomic
Date: Wed, 23 Sep 2020 15:04:35 -0700 [thread overview]
Message-ID: <202009231502.20F24788E@keescook> (raw)
In-Reply-To: <4ec035ae-efbf-d4b9-cf11-d6e3819a7edc@linuxfoundation.org>
On Wed, Sep 23, 2020 at 03:19:08PM -0600, Shuah Khan wrote:
> On 9/23/20 2:58 PM, Kees Cook wrote:
> > On Wed, Sep 23, 2020 at 02:48:22PM -0600, Shuah Khan wrote:
> > > On 9/23/20 1:04 PM, Kees Cook wrote:
> > > > On Tue, Sep 22, 2020 at 07:43:30PM -0600, Shuah Khan wrote:
> > > > I would really like these APIs to be _impossible_ to use for object
> > > > lifetime management. To that end, I would like to have all of the
> > > > *_return() functions removed. It should be strictly init, inc, dec,
> > > > read.
> > > >
> > >
> > > Yes. I am with you on making this API as small as possible so it won't
> > > be used for lifetime mgmt. That means no support for:
> > >
> > > *_test, add_negative etc.
> > >
> > > I started out with just init, inc, dec, read. As I started looking
> > > for candidates that can be converted to counters, I found inc_return()
> > > usages. I think we need inc_return() for sure. I haven't come across
> > > atomic_dec_return() yet.
> >
> > What are the inc_return() cases? If they're not "safe" to use inc() and
> > then read(), then those likely need a closer look at what they're doing.
> >
>
> 3 in this series I sent. I would say I barely scratched the surface
> when it comes to finding candidates for converting.
>
> drivers/android/binder.c
> drivers/acpi/acpi_extlog.c
> drivers/acpi/apei/ghes.c
>
> These uses look reasonable to me. Having this inc_return() will save
> making _inc() followed by _read()
I'd like to make sure it's clear that it should not be treated as atomic
(even if it is), so a separate _read(), I think, makes that clear. And
hopefully it'll keep people from ever trying to sneak a _dec_return()
in. :)
> I will change counter to counter_simple and add a warning that this
> should only be used when atomic isn't needed. I can outline some
> tips for choosing the right one.
Okay.
--
Kees Cook
next prev parent reply other threads:[~2020-09-23 22:04 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-23 1:43 [RFC PATCH 00/11] Introduce Simple atomic and non-atomic counters Shuah Khan
2020-09-23 1:43 ` [RFC PATCH 01/11] counters: Introduce counter and counter_atomic Shuah Khan
2020-09-23 10:35 ` Greg KH
2020-09-23 19:04 ` Kees Cook
2020-09-23 19:34 ` Greg KH
2020-09-23 20:54 ` Kees Cook
2020-09-23 20:48 ` Shuah Khan
2020-09-23 20:58 ` Kees Cook
2020-09-23 21:19 ` Shuah Khan
2020-09-23 22:04 ` Kees Cook [this message]
2020-09-23 1:43 ` [RFC PATCH 02/11] selftests:lib: add new test for counters Shuah Khan
2020-09-23 1:43 ` [RFC PATCH 03/11] drivers/base: convert deferred_trigger_count and probe_count to counter_atomic Shuah Khan
2020-09-23 10:30 ` Greg KH
2020-09-23 1:43 ` [RFC PATCH 04/11] drivers/base/devcoredump: convert devcd_count " Shuah Khan
2020-09-23 10:31 ` Greg KH
2020-09-23 1:43 ` [RFC PATCH 05/11] drivers/acpi: convert seqno counter_atomic Shuah Khan
2020-09-24 11:13 ` Rafael J. Wysocki
2020-09-24 15:08 ` Shuah Khan
2020-09-24 15:32 ` Rafael J. Wysocki
2020-09-23 1:43 ` [RFC PATCH 06/11] drivers/acpi/apei: " Shuah Khan
2020-09-23 1:43 ` [RFC PATCH 07/11] drivers/android/binder: convert stats, transaction_log to counter_atomic Shuah Khan
2020-09-23 5:10 ` Greg KH
2020-09-23 19:04 ` Kees Cook
2020-09-23 19:31 ` Greg KH
2020-09-23 20:51 ` Kees Cook
2020-09-23 1:43 ` [RFC PATCH 08/11] drivers/base/test/test_async_driver_probe: convert to use counter_atomic Shuah Khan
2020-09-23 10:33 ` Greg KH
2020-09-23 1:43 ` [RFC PATCH 09/11] drivers/char/ipmi: convert stats " Shuah Khan
2020-09-23 1:43 ` [RFC PATCH 10/11] drivers/misc/vmw_vmci: convert num guest devices counter to counter_atomic Shuah Khan
2020-09-23 10:29 ` Greg KH
2020-09-23 1:43 ` [RFC PATCH 11/11] drivers/edac: convert pci counters " 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=202009231502.20F24788E@keescook \
--to=keescook@chromium.org \
--cc=corbet@lwn.net \
--cc=gregkh@linuxfoundation.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=skhan@linuxfoundation.org \
/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: link
Be 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.