All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: Shuah Khan <skhan@linuxfoundation.org>
Cc: johannes@sipsolutions.net, gregkh@linuxfoundation.org,
	rafael@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 04/11] drivers/base/devcoredump: convert devcd_count to counter_atomic32
Date: Wed, 7 Oct 2020 11:15:44 -0700	[thread overview]
Message-ID: <202010071114.EE9A2A47C@keescook> (raw)
In-Reply-To: <462fd514dfe2afbb8faa1dea4cdb4b0e75d8e8da.1602011710.git.skhan@linuxfoundation.org>

On Tue, Oct 06, 2020 at 02:44:35PM -0600, Shuah Khan wrote:
> counter_atomic* is introduced to be used when a variable is used as
> a simple counter and doesn't guard object lifetimes. This clearly
> differentiates atomic_t usages that guard object lifetimes.
> 
> counter_atomic* variables 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.
> 
> devcd_count is used to track dev_coredumpm device count and used in
> device name string. It doesn't guard object lifetimes, device usage
> counts, device open counts, and pm states. There is very little chance
> of this counter overflowing. Convert it to use counter_atomic32.
> 
> This conversion doesn't change the overflow wrap around behavior.
> 
> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>

I actually wonder if this should use refcount_t just because it is
designed to be an alway-unique value. It is hard to imagine ever causing
this to overflow, but why not let it be protected?

-- 
Kees Cook

  reply	other threads:[~2020-10-07 18:15 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-06 20:44 [PATCH v2 00/11] Introduce Simple atomic counters Shuah Khan
2020-10-06 20:44 ` [PATCH v2 01/11] counters: Introduce counter_atomic* counters Shuah Khan
2020-10-07  9:04   ` Greg KH
2020-10-08 17:18     ` Shuah Khan
2020-10-07 18:11   ` Kees Cook
2020-10-07 19:26     ` Shuah Khan
2020-10-07 20:30       ` Kees Cook
2020-10-06 20:44 ` [PATCH v2 02/11] selftests:lib:test_counters: add new test for counters Shuah Khan
2020-10-07 18:12   ` Kees Cook
2020-10-06 20:44 ` [PATCH v2 03/11] drivers/base: convert deferred_trigger_count and probe_count to counter_atomic32 Shuah Khan
2020-10-07 18:13   ` Kees Cook
2020-10-06 20:44 ` [PATCH v2 04/11] drivers/base/devcoredump: convert devcd_count " Shuah Khan
2020-10-07 18:15   ` Kees Cook [this message]
2020-10-07 19:33     ` Shuah Khan
2020-10-07 19:38       ` Johannes Berg
2020-10-07 19:59         ` Shuah Khan
2020-10-07 20:43         ` Kees Cook
2020-10-08  6:42           ` Johannes Berg
2020-10-08  7:37             ` Kees Cook
2020-10-06 20:44 ` [PATCH v2 05/11] drivers/acpi: convert seqno counter_atomic32 Shuah Khan
2020-10-07 18:16   ` Kees Cook
2020-10-06 20:44 ` [PATCH v2 06/11] drivers/acpi/apei: " Shuah Khan
2020-10-07 18:17   ` Kees Cook
2020-10-06 20:44 ` [PATCH v2 07/11] drivers/android/binder: convert stats, transaction_log to counter_atomic32 Shuah Khan
2020-10-07 18:18   ` Kees Cook
2020-10-09 12:39   ` Christian Brauner
2020-10-06 20:44 ` [PATCH v2 08/11] drivers/base/test/test_async_driver_probe: convert to use counter_atomic32 Shuah Khan
2020-10-07 18:20   ` Kees Cook
2020-10-06 20:44 ` [PATCH v2 09/11] drivers/char/ipmi: convert stats " Shuah Khan
2020-10-07 18:21   ` Kees Cook
2020-10-06 20:44 ` [PATCH v2 10/11] drivers/misc/vmw_vmci: convert num guest devices counter to counter_atomic32 Shuah Khan
2020-10-07 18:27   ` Kees Cook
2020-10-08 17:12     ` Shuah Khan
2020-10-06 20:44 ` [PATCH v2 11/11] drivers/edac: convert pci counters " Shuah Khan
2020-10-07 18:28   ` Kees Cook
2020-10-07 18:30 ` [PATCH v2 00/11] Introduce Simple atomic counters Kees Cook

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=202010071114.EE9A2A47C@keescook \
    --to=keescook@chromium.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=johannes@sipsolutions.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rafael@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.