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
prev parent reply other threads:[~2020-09-23 22:04 UTC|newest]
Thread overview: 10+ 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]
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).