On Mon, Oct 25, 2021 at 08:51:40PM +0100, Matthew Wilcox wrote:
> On Mon, Oct 25, 2021 at 12:29:46PM -0700, Kees Cook wrote:
> > On Mon, Oct 25, 2021 at 07:16:34PM +0100, Matthew Wilcox (Oracle) wrote:
> > > Commit 110860541f44 ("mm/secretmem: use refcount_t instead of atomic_t")
> > > attempted to fix the problem of secretmem_users wrapping to zero and
> > > allowing suspend once again. Prevent secretmem_users from wrapping to
> > > zero by forbidding new users if the number of users has wrapped from
> > > positive to negative. This stops a long way short of reaching the
> > > necessary 4 billion users, so there's no need to be clever with special
> > > anti-wrap types or checking the return value from atomic_inc().
> >
> > I still prefer refcount_t here because it provides deterministic
> > saturation, but the risk right now is so narrow ("don't hibernate"),
> > I'm not going to fight for it. I think it'd be fine to use it initialized
> > to 1, and have the removal check for == 0 as a failure state, which would
> > deterministically cover the underflow case too.
>
> I still think that's abusing the refcount_t pattern. refcount_t should
> be for ... reference counts. Not these other things.
Is secretmem different? We're trying to count how many of these we have,
this is a common pattern in, for example, the network code which does
this kind of thing a lot.
It's just that for a "global" counter like here, we're not tied to a
specific object's lifetime, but usually some global state that depends
on having _any_ of the objects alive.
--
Kees Cook
