All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: Joel Fernandes <joel@joelfernandes.org>
Cc: Shuah Khan <skhan@linuxfoundation.org>,
	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,
	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
Subject: Re: [PATCH 00/11] Introduce Simple atomic and non-atomic counters
Date: Mon, 28 Sep 2020 13:34:31 -0700	[thread overview]
Message-ID: <202009281331.444F36A7B@keescook> (raw)
In-Reply-To: <20200927233526.GA500818@google.com>

On Sun, Sep 27, 2020 at 07:35:26PM -0400, Joel Fernandes wrote:
> On Fri, Sep 25, 2020 at 05:47:14PM -0600, Shuah Khan wrote:
> > This patch series is a result of discussion at the refcount_t BOF
> > the Linux Plumbers Conference. In this discussion, we identified
> > a need for looking closely and investigating atomic_t usages in
> > the kernel when it is used strictly as a counter without it
> > controlling object lifetimes and state changes.
> > 
> > There are a number of atomic_t usages in the kernel where atomic_t api
> > is used strictly for counting and not for managing object lifetime. In
> > some cases, atomic_t might not even be needed.
> >     
> > The purpose of these counters is twofold: 1. clearly differentiate
> > atomic_t counters from atomic_t usages that guard object lifetimes,
> > hence prone to overflow and underflow errors. It allows tools that scan
> > for underflow and overflow on atomic_t usages to detect overflow and
> > underflows to scan just the cases that are prone to errors. 2. provides
> > non-atomic counters for cases where atomic isn't necessary.
> 
> Nice series :)
> 
> It appears there is no user of counter_simple in this series other than the
> selftest. Would you be planning to add any conversions in the series itself,
> for illustration of use? Sorry if I missed a usage.
> 
> Also how do we guard against atomicity of counter_simple RMW operations? Is
> the implication that it should be guarded using other synchronization to
> prevent lost-update problem?
> 
> Some more comments:
> 
> 1.  atomic RMW operations that have a return value are fully ordered. Would
>     you be adding support to counter_simple for such ordering as well, for
>     consistency?

No -- there is no atomicity guarantee for counter_simple. I would prefer
counter_simple not exist at all, specifically for this reason.

> 2. I felt counter_atomic and counter_atomic64 would be nice equivalents to
>    the atomic and atomic64 naming currently used (i.e. dropping the '32').
>    However that is just my opinion and I am ok with either naming.

I had asked that they be size-named to avoid any confusion (i.e. we're
making a new API).

-- 
Kees Cook

WARNING: multiple messages have this Message-ID (diff)
From: Kees Cook <keescook@chromium.org>
To: Joel Fernandes <joel@joelfernandes.org>
Cc: rafael@kernel.org, linux-kselftest@vger.kernel.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 13:34:31 -0700	[thread overview]
Message-ID: <202009281331.444F36A7B@keescook> (raw)
In-Reply-To: <20200927233526.GA500818@google.com>

On Sun, Sep 27, 2020 at 07:35:26PM -0400, Joel Fernandes wrote:
> On Fri, Sep 25, 2020 at 05:47:14PM -0600, Shuah Khan wrote:
> > This patch series is a result of discussion at the refcount_t BOF
> > the Linux Plumbers Conference. In this discussion, we identified
> > a need for looking closely and investigating atomic_t usages in
> > the kernel when it is used strictly as a counter without it
> > controlling object lifetimes and state changes.
> > 
> > There are a number of atomic_t usages in the kernel where atomic_t api
> > is used strictly for counting and not for managing object lifetime. In
> > some cases, atomic_t might not even be needed.
> >     
> > The purpose of these counters is twofold: 1. clearly differentiate
> > atomic_t counters from atomic_t usages that guard object lifetimes,
> > hence prone to overflow and underflow errors. It allows tools that scan
> > for underflow and overflow on atomic_t usages to detect overflow and
> > underflows to scan just the cases that are prone to errors. 2. provides
> > non-atomic counters for cases where atomic isn't necessary.
> 
> Nice series :)
> 
> It appears there is no user of counter_simple in this series other than the
> selftest. Would you be planning to add any conversions in the series itself,
> for illustration of use? Sorry if I missed a usage.
> 
> Also how do we guard against atomicity of counter_simple RMW operations? Is
> the implication that it should be guarded using other synchronization to
> prevent lost-update problem?
> 
> Some more comments:
> 
> 1.  atomic RMW operations that have a return value are fully ordered. Would
>     you be adding support to counter_simple for such ordering as well, for
>     consistency?

No -- there is no atomicity guarantee for counter_simple. I would prefer
counter_simple not exist at all, specifically for this reason.

> 2. I felt counter_atomic and counter_atomic64 would be nice equivalents to
>    the atomic and atomic64 naming currently used (i.e. dropping the '32').
>    However that is just my opinion and I am ok with either naming.

I had asked that they be size-named to avoid any confusion (i.e. we're
making a new API).

-- 
Kees Cook
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

  reply	other threads:[~2020-09-28 20:34 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
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 [this message]
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=202009281331.444F36A7B@keescook \
    --to=keescook@chromium.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=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=skhan@linuxfoundation.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: 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.