From: Johannes Berg <johannes@sipsolutions.net>
To: Kees Cook <keescook@chromium.org>
Cc: Shuah Khan <skhan@linuxfoundation.org>,
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: Thu, 08 Oct 2020 08:42:22 +0200 [thread overview]
Message-ID: <1545e7c77675c9a0574a7582ee5f0c969c01419e.camel@sipsolutions.net> (raw)
In-Reply-To: <202010071334.8298F3FA7@keescook> (sfid-20201007_224326_651899_546CB035)
On Wed, 2020-10-07 at 13:43 -0700, Kees Cook wrote:
> > > > 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?
> > > >
> > >
> > > This is one of the cases where devcd_count doesn't guard lifetimes,
> > > however if it ever overflows, refcount_t is a better choice.
> > >
> > > If we decide refcount_t is a better choice, I can drop this patch
> > > and send refcount_t conversion patch instead.
> > >
> > > Greg! Any thoughts on refcount_t for this being a better choice?
> >
> > I'm not Greg, but ... there's a 5 minute timeout. So in order to cause a
> > clash you'd have to manage to overflow the counter within a 5 minute
> > interval, otherwise you can actually reuse the numbers starting again
> > from 0 without any ill effect.
>
> That's not true as far as I can see: there's no reset in here. It's a
> global heap variable with function-level visibility (note the "static"),
> so it is only ever initialized once:
Yes, obviously it is a static variable. You'll note that I also never
claimed anything regarding reset.
What I said was two things (perhaps with too many words :-) ):
1) each value that we derive from this ever-incrementing (modulo 2^32)
variable only get used for a limited amount of time (max. 5 minutes)
2) if you manage to overflow within 5 minutes, then the following
device_add() will just fail and nothing else/bad will happen
Therefore, there's no problem with wrapping, and IMHO it'd be *better*
than saturating because (1) means that the wrapping almost certainly
doesn't matter, and (2) means that even if you do manage to wrap and
cause a "clash" (what I wrote in the text you quoted) this is entirely
harmless.
OTOH, if you saturate, then - again under the premise of actually
getting there, however unlikely it may be - you are afterwards *always*
hitting (2), regardless of (1), which seems counter-productive given
that (1) means that (2) almost certainly won't happen.
IOW, I disagree with you, and think that counter_atomic_32 is more
appropriate here than refcount_t.
johannes
next prev parent reply other threads:[~2020-10-08 6:42 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
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 [this message]
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=1545e7c77675c9a0574a7582ee5f0c969c01419e.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=gregkh@linuxfoundation.org \
--cc=keescook@chromium.org \
--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 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).