linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Will Deacon <will@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	 Borislav Petkov <bp@alien8.de>,
	Xiyu Yang <xiyuyang19@fudan.edu.cn>,
	 Alistair Popple <apopple@nvidia.com>,
	Yang Shi <shy828301@gmail.com>,
	 Shakeel Butt <shakeelb@google.com>,
	Hugh Dickins <hughd@google.com>,
	 Miaohe Lin <linmiaohe@huawei.com>,
	 Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux-MM <linux-mm@kvack.org>,
	 yuanxzhang@fudan.edu.cn, Xin Tan <tanxin.ctf@gmail.com>,
	 Will Deacon <will.deacon@arm.com>,
	David Howells <dhowells@redhat.com>
Subject: Re: [PATCH] mm/rmap: Convert from atomic_t to refcount_t on anon_vma->refcount
Date: Thu, 19 Aug 2021 12:09:37 -0700	[thread overview]
Message-ID: <CAHk-=wh_vEzmYnMufOa=03WAU=DRM5+n6uZy=dVtJERFJm3Q-Q@mail.gmail.com> (raw)
In-Reply-To: <YR52igt/lJ7gQqOG@hirez.programming.kicks-ass.net>

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.

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.

> 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.

You want to fail if the old value was negative, or if the old value
was less than what you subtracted. That's literally the "less than"
operator.

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.

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.

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.

Giving people who want a smaller kernel the option to do so, while
giving people who want checking the option too.

                Linus


  reply	other threads:[~2021-08-19 19:09 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-19  3:23 [PATCH] mm/rmap: Convert from atomic_t to refcount_t on anon_vma->refcount Xiyu Yang
2021-07-20 23:01 ` Andrew Morton
2021-08-19 13:21   ` Will Deacon
2021-08-19 14:06     ` Peter Zijlstra
2021-08-19 15:19       ` Peter Zijlstra
2021-08-19 19:09         ` Linus Torvalds [this message]
2021-08-20  6:43           ` Peter Zijlstra
2021-08-20  7:33             ` Kees Cook
2021-08-20  8:16             ` Peter Zijlstra
2021-08-20  8:24               ` Will Deacon
2021-08-20  9:03                 ` Peter Zijlstra
2021-08-20 17:26                   ` 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='CAHk-=wh_vEzmYnMufOa=03WAU=DRM5+n6uZy=dVtJERFJm3Q-Q@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=apopple@nvidia.com \
    --cc=bp@alien8.de \
    --cc=dhowells@redhat.com \
    --cc=hughd@google.com \
    --cc=linmiaohe@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=peterz@infradead.org \
    --cc=shakeelb@google.com \
    --cc=shy828301@gmail.com \
    --cc=tanxin.ctf@gmail.com \
    --cc=will.deacon@arm.com \
    --cc=will@kernel.org \
    --cc=xiyuyang19@fudan.edu.cn \
    --cc=yuanxzhang@fudan.edu.cn \
    /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).