[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 15 Mar 2021 15:19:17 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Kees Cook <keescook@...omium.org>
Cc: Alexey Gladkov <gladkov.alexey@...il.com>, LKML <linux-kernel@...r.kernel.org>,
io-uring <io-uring@...r.kernel.org>,
Kernel Hardening <kernel-hardening@...ts.openwall.com>,
Linux Containers <containers@...ts.linux-foundation.org>, Linux-MM <linux-mm@...ck.org>,
Alexey Gladkov <legion@...nel.org>, Andrew Morton <akpm@...ux-foundation.org>,
Christian Brauner <christian.brauner@...ntu.com>, "Eric W . Biederman" <ebiederm@...ssion.com>,
Jann Horn <jannh@...gle.com>, Jens Axboe <axboe@...nel.dk>, Oleg Nesterov <oleg@...hat.com>
Subject: Re: [PATCH v8 3/8] Use atomic_t for ucounts reference counting
On Mon, Mar 15, 2021 at 3:03 PM Kees Cook <keescook@...omium.org> wrote:
>
> On Wed, Mar 10, 2021 at 01:01:28PM +0100, Alexey Gladkov wrote:
> > The current implementation of the ucounts reference counter requires the
> > use of spin_lock. We're going to use get_ucounts() in more performance
> > critical areas like a handling of RLIMIT_SIGPENDING.
>
> This really looks like it should be refcount_t.
No.
refcount_t didn't have the capabilities required.
It just saturates, and doesn't have the "don't do this" case, which
the ucounts case *DOES* have.
In other words, refcount_t is entirely misdesigned for this - because
it's literally designed for "people can't handle overflow, so we warn
and saturate".
ucounts can never saturate, because they replace saturation with
"don't do that then".
In other words, ucounts work like the page counts do (which also don't
saturate, they just say "ok, you can't get a reference".
I know you are attached to refcounts, but really: they are not only
more expensive, THEY LITERALLY DO THE WRONG THING.
Linus
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
