Re: [PATCH v2 04/11] drivers/base/devcoredump: convert devcd_count to counter_atomic32

[Johannes Berg]

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