Re: [PATCH] mm/rmap: Convert from atomic_t to refcount_t on anon_vma->refcount

[Peter Zijlstra <peterz@infradead.org>]

On Thu, Aug 19, 2021 at 12:09:37PM -0700, Linus Torvalds wrote:
> On Thu, Aug 19, 2021 at 8:21 AM Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > If we can skip the OF... we can do something like this:
> 
> Honestly, I think a lot of the refcount code is questionable. It was
> absolutely written with no care for performance AT ALL.

That's a bit unfair I feel. Will's last rewrite of the stuff was
specifically to address performance issues.

> I'm not sure it helps to then add arch-specific code for it without
> thinking it through a _lot_ first.
> 
> It might be better to just have a "atomic_t with overflow handling" in
> general, exactly because the refcount_t was designed and written
> without any regard for code that cares about performance.

The primary concern was to use a single unconditional atomic op where
possible (mostly fetch_add), as the atomic op dominates whatever else it
does. The rest is just because C absolutely sucks at conditions.

Doing atomic_t with overflow handling would require doing the whole
thing in arch asm.

> > static inline bool refcount_dec_and_test(refcount_t *r)
> > {
> >         asm_volatile_goto (LOCK_PREFIX "decl %[var]\n\t"
> >                            "jz %l[cc_zero]\n\t"
> >                            "jns 1f\n\t"
> 
> I think you can use "jl" for the bad case.

Duh yes. I clearly didn't have my head on straight.

> I think it's better to handle that case out-of-line than play games
> with UD, though - this is going to be the rare case, the likelihood
> that we get the fixup wrong is just too big. Once it's out-of-line
> it's not as critical any more, even if it does add to the size of the
> code.

Fine with me; although the immediate complaint from Andrew was about
size, hence my UD1 hackery.

> So if we do this, I think it should be something like
> 
>    static inline __must_check bool refcount_dec_and_test(refcount_t *r)
>    {
>         asm_volatile_goto (LOCK_PREFIX "decl %[var]\n\t"
>                 "jz %l[cc_zero]\n\t"
>                 "jl %l[cc_error]"
>                 : : [var] "m" (r->refs.counter)
>                 : "memory" : cc_zero, cc_error);
> 
>         return false;
> 
>    cc_zero:
>         return true;
>    cc_error:
>         refcount_warn_saturate(r, REFCOUNT_SUB_UAF);
>         return false;
>    }
> 
> and we can discuss whether we could improve on the
> refcount_warn_saturate() separately.

I can do the refcount_warn_saturate() change separately.

Let me go check how small I can get it...

> But see above: maybe just make this a separate "careful atomic_t",
> with the option to panic-on-overflow. So then we could get rid of
> refcount_warn_saturate() enmtirely above, and instead just have a
> (compile-time option) BUG() case, with the non-careful version just
> being our existing atomic_dec_and_test.

We used to have that option; the argument was made that everybody cares
about security and as long as this doesn't show up on benchmarks we
good.

Also, I don't think most people want the overflow to go BUG, WARN is
mostly the right thing and only the super paranoid use panic-on-warn or
something.