All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joel Fernandes <joel@joelfernandes.org>
To: Shuah Khan <skhan@linuxfoundation.org>
Cc: corbet@lwn.net, keescook@chromium.org,
	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: Sun, 27 Sep 2020 19:35:26 -0400	[thread overview]
Message-ID: <20200927233526.GA500818@google.com> (raw)
In-Reply-To: <cover.1601073127.git.skhan@linuxfoundation.org>

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?

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.

thanks!

 - Joel

>     
> Simple atomic and non-atomic counters api provides interfaces for simple
> atomic and non-atomic counters that just count, and don't guard resource
> lifetimes. Counters will wrap around to 0 when it overflows and should
> not be used to guard resource lifetimes, device usage and open counts
> that control state changes, and pm states.
>     
> Using counter_atomic to guard lifetimes could lead to use-after free
> when it overflows and undefined behavior when used to manage state
> changes and device usage/open states.
> 
> This patch series introduces Simple atomic and non-atomic counters.
> Counter atomic ops leverage atomic_t and provide a sub-set of atomic_t
> ops.
> 
> In addition this patch series converts a few drivers to use the new api.
> The following criteria is used for select variables for conversion:
> 
> 1. Variable doesn't guard object lifetimes, manage state changes e.g:
>    device usage counts, device open counts, and pm states.
> 2. Variable is used for stats and counters.
> 3. The conversion doesn't change the overflow behavior.
> 
> Changes since RFC:
> -- Thanks for reviews and reviewed-by, and Acked-by tags. Updated
>    the patches with the tags.
> -- 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.
>    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. 
> -- Updated driver patches with API name changes.
> -- We discussed if binder counters can be non-atomic. For now I left
>    them the same as the RFC patch - using counter_atomic32
> -- Unrelated to this patch series:
>    The patch series review uncovered improvements could be made to
>    test_async_driver_probe and vmw_vmci/vmci_guest. I will track
>    these for fixing later.
> 
> Shuah Khan (11):
>   counters: Introduce counter_simple* and counter_atomic* counters
>   selftests:lib:test_counters: add new test for counters
>   drivers/base: convert deferred_trigger_count and probe_count to
>     counter_atomic32
>   drivers/base/devcoredump: convert devcd_count to counter_atomic32
>   drivers/acpi: convert seqno counter_atomic32
>   drivers/acpi/apei: convert seqno counter_atomic32
>   drivers/android/binder: convert stats, transaction_log to
>     counter_atomic32
>   drivers/base/test/test_async_driver_probe: convert to use
>     counter_atomic32
>   drivers/char/ipmi: convert stats to use counter_atomic32
>   drivers/misc/vmw_vmci: convert num guest devices counter to
>     counter_atomic32
>   drivers/edac: convert pci counters to counter_atomic32
> 
>  Documentation/core-api/counters.rst          | 174 +++++++++
>  MAINTAINERS                                  |   8 +
>  drivers/acpi/acpi_extlog.c                   |   5 +-
>  drivers/acpi/apei/ghes.c                     |   5 +-
>  drivers/android/binder.c                     |  41 +--
>  drivers/android/binder_internal.h            |   3 +-
>  drivers/base/dd.c                            |  19 +-
>  drivers/base/devcoredump.c                   |   5 +-
>  drivers/base/test/test_async_driver_probe.c  |  23 +-
>  drivers/char/ipmi/ipmi_msghandler.c          |   9 +-
>  drivers/char/ipmi/ipmi_si_intf.c             |   9 +-
>  drivers/edac/edac_pci.h                      |   5 +-
>  drivers/edac/edac_pci_sysfs.c                |  28 +-
>  drivers/misc/vmw_vmci/vmci_guest.c           |   9 +-
>  include/linux/counters.h                     | 350 +++++++++++++++++++
>  lib/Kconfig                                  |  10 +
>  lib/Makefile                                 |   1 +
>  lib/test_counters.c                          | 276 +++++++++++++++
>  tools/testing/selftests/lib/Makefile         |   1 +
>  tools/testing/selftests/lib/config           |   1 +
>  tools/testing/selftests/lib/test_counters.sh |   5 +
>  21 files changed, 913 insertions(+), 74 deletions(-)
>  create mode 100644 Documentation/core-api/counters.rst
>  create mode 100644 include/linux/counters.h
>  create mode 100644 lib/test_counters.c
>  create mode 100755 tools/testing/selftests/lib/test_counters.sh
> 
> -- 
> 2.25.1
> 

WARNING: multiple messages have this Message-ID (diff)
From: Joel Fernandes <joel@joelfernandes.org>
To: Shuah Khan <skhan@linuxfoundation.org>
Cc: rafael@kernel.org, linux-kselftest@vger.kernel.org,
	rric@kernel.org, shuah@kernel.org, devel@driverdev.osuosl.org,
	arnd@arndb.de, corbet@lwn.net, surenb@google.com,
	linux-doc@vger.kernel.org, linux-acpi@vger.kernel.org,
	lenb@kernel.org, tkjos@android.com, keescook@chromium.org,
	minyard@acm.org, bp@alien8.de,
	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: Sun, 27 Sep 2020 19:35:26 -0400	[thread overview]
Message-ID: <20200927233526.GA500818@google.com> (raw)
In-Reply-To: <cover.1601073127.git.skhan@linuxfoundation.org>

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?

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.

thanks!

 - Joel

>     
> Simple atomic and non-atomic counters api provides interfaces for simple
> atomic and non-atomic counters that just count, and don't guard resource
> lifetimes. Counters will wrap around to 0 when it overflows and should
> not be used to guard resource lifetimes, device usage and open counts
> that control state changes, and pm states.
>     
> Using counter_atomic to guard lifetimes could lead to use-after free
> when it overflows and undefined behavior when used to manage state
> changes and device usage/open states.
> 
> This patch series introduces Simple atomic and non-atomic counters.
> Counter atomic ops leverage atomic_t and provide a sub-set of atomic_t
> ops.
> 
> In addition this patch series converts a few drivers to use the new api.
> The following criteria is used for select variables for conversion:
> 
> 1. Variable doesn't guard object lifetimes, manage state changes e.g:
>    device usage counts, device open counts, and pm states.
> 2. Variable is used for stats and counters.
> 3. The conversion doesn't change the overflow behavior.
> 
> Changes since RFC:
> -- Thanks for reviews and reviewed-by, and Acked-by tags. Updated
>    the patches with the tags.
> -- 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.
>    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. 
> -- Updated driver patches with API name changes.
> -- We discussed if binder counters can be non-atomic. For now I left
>    them the same as the RFC patch - using counter_atomic32
> -- Unrelated to this patch series:
>    The patch series review uncovered improvements could be made to
>    test_async_driver_probe and vmw_vmci/vmci_guest. I will track
>    these for fixing later.
> 
> Shuah Khan (11):
>   counters: Introduce counter_simple* and counter_atomic* counters
>   selftests:lib:test_counters: add new test for counters
>   drivers/base: convert deferred_trigger_count and probe_count to
>     counter_atomic32
>   drivers/base/devcoredump: convert devcd_count to counter_atomic32
>   drivers/acpi: convert seqno counter_atomic32
>   drivers/acpi/apei: convert seqno counter_atomic32
>   drivers/android/binder: convert stats, transaction_log to
>     counter_atomic32
>   drivers/base/test/test_async_driver_probe: convert to use
>     counter_atomic32
>   drivers/char/ipmi: convert stats to use counter_atomic32
>   drivers/misc/vmw_vmci: convert num guest devices counter to
>     counter_atomic32
>   drivers/edac: convert pci counters to counter_atomic32
> 
>  Documentation/core-api/counters.rst          | 174 +++++++++
>  MAINTAINERS                                  |   8 +
>  drivers/acpi/acpi_extlog.c                   |   5 +-
>  drivers/acpi/apei/ghes.c                     |   5 +-
>  drivers/android/binder.c                     |  41 +--
>  drivers/android/binder_internal.h            |   3 +-
>  drivers/base/dd.c                            |  19 +-
>  drivers/base/devcoredump.c                   |   5 +-
>  drivers/base/test/test_async_driver_probe.c  |  23 +-
>  drivers/char/ipmi/ipmi_msghandler.c          |   9 +-
>  drivers/char/ipmi/ipmi_si_intf.c             |   9 +-
>  drivers/edac/edac_pci.h                      |   5 +-
>  drivers/edac/edac_pci_sysfs.c                |  28 +-
>  drivers/misc/vmw_vmci/vmci_guest.c           |   9 +-
>  include/linux/counters.h                     | 350 +++++++++++++++++++
>  lib/Kconfig                                  |  10 +
>  lib/Makefile                                 |   1 +
>  lib/test_counters.c                          | 276 +++++++++++++++
>  tools/testing/selftests/lib/Makefile         |   1 +
>  tools/testing/selftests/lib/config           |   1 +
>  tools/testing/selftests/lib/test_counters.sh |   5 +
>  21 files changed, 913 insertions(+), 74 deletions(-)
>  create mode 100644 Documentation/core-api/counters.rst
>  create mode 100644 include/linux/counters.h
>  create mode 100644 lib/test_counters.c
>  create mode 100755 tools/testing/selftests/lib/test_counters.sh
> 
> -- 
> 2.25.1
> 
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

  parent reply	other threads:[~2020-09-27 23:35 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 [this message]
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=20200927233526.GA500818@google.com \
    --to=joel@joelfernandes.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=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=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.