All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jens Axboe <axboe@kernel.dk>,
	Kernel Hardening <kernel-hardening@lists.openwall.com>,
	Linux Containers <containers@lists.linux-foundation.org>,
	Jann Horn <jannh@google.com>, LKML <linux-kernel@vger.kernel.org>,
	Oleg Nesterov <oleg@redhat.com>, Linux-MM <linux-mm@kvack.org>,
	"Eric W . Biederman" <ebiederm@xmission.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Alexey Gladkov <legion@kernel.org>,
	io-uring <io-uring@vger.kernel.org>
Subject: Re: [PATCH v8 3/8] Use atomic_t for ucounts reference counting
Date: Tue, 16 Mar 2021 12:32:57 -0700	[thread overview]
Message-ID: <202103161229.75FDE42F@keescook> (raw)
In-Reply-To: <CAHk-=wj7k2nCB8Q5kMYsYi1ajb99yZ-EYn_MYFMQ2bw3nWuT5Q@mail.gmail.com>

On Tue, Mar 16, 2021 at 12:26:05PM -0700, Linus Torvalds wrote:
> Note that the above very intentionally does allow the "we can go over
> the limit" case for another reason: we still have that regular
> *unconditional* get_page(), that has a "I absolutely need a temporary
> ref to this page, but I know it's not some long-term thing that a user
> can force". That's not only our traditional model, but it's something
> that some kernel code simply does need, so it's a good feature in
> itself. That might be less of an issue for ucounts, but for pages, we
> somethines do have "I need to take a ref to this page just for my own
> use while I then drop the page lock and do something else".

Right, get_page() has a whole other set of requirements. :) I just
couldn't find the "we _must_ to get a reference to ucounts" code path,
so I was scratching my head.

> And it's possible that "refcount_t" could use that exact same model,
> and actually then offer that option that ucounts wants, of a "try to
> get a refcount, but if we have too many refcounts, then never mind, I
> can just return an error to user space instead".

Yeah, if there starts to be more of these cases, I think it'd be a
nice addition. And with the recent performance work Will Deacon did on
refcount_t, I think any general performance concerns are met now. But
I'd love to just leave refcount_t alone until we can really show a need
for an API change. :P

-- 
Kees Cook
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers

WARNING: multiple messages have this Message-ID (diff)
From: Kees Cook <keescook@chromium.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Alexey Gladkov <gladkov.alexey@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>,
	io-uring <io-uring@vger.kernel.org>,
	Kernel Hardening <kernel-hardening@lists.openwall.com>,
	Linux Containers <containers@lists.linux-foundation.org>,
	Linux-MM <linux-mm@kvack.org>, Alexey Gladkov <legion@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Christian Brauner <christian.brauner@ubuntu.com>,
	"Eric W . Biederman" <ebiederm@xmission.com>,
	Jann Horn <jannh@google.com>, Jens Axboe <axboe@kernel.dk>,
	Oleg Nesterov <oleg@redhat.com>
Subject: Re: [PATCH v8 3/8] Use atomic_t for ucounts reference counting
Date: Tue, 16 Mar 2021 12:32:57 -0700	[thread overview]
Message-ID: <202103161229.75FDE42F@keescook> (raw)
In-Reply-To: <CAHk-=wj7k2nCB8Q5kMYsYi1ajb99yZ-EYn_MYFMQ2bw3nWuT5Q@mail.gmail.com>

On Tue, Mar 16, 2021 at 12:26:05PM -0700, Linus Torvalds wrote:
> Note that the above very intentionally does allow the "we can go over
> the limit" case for another reason: we still have that regular
> *unconditional* get_page(), that has a "I absolutely need a temporary
> ref to this page, but I know it's not some long-term thing that a user
> can force". That's not only our traditional model, but it's something
> that some kernel code simply does need, so it's a good feature in
> itself. That might be less of an issue for ucounts, but for pages, we
> somethines do have "I need to take a ref to this page just for my own
> use while I then drop the page lock and do something else".

Right, get_page() has a whole other set of requirements. :) I just
couldn't find the "we _must_ to get a reference to ucounts" code path,
so I was scratching my head.

> And it's possible that "refcount_t" could use that exact same model,
> and actually then offer that option that ucounts wants, of a "try to
> get a refcount, but if we have too many refcounts, then never mind, I
> can just return an error to user space instead".

Yeah, if there starts to be more of these cases, I think it'd be a
nice addition. And with the recent performance work Will Deacon did on
refcount_t, I think any general performance concerns are met now. But
I'd love to just leave refcount_t alone until we can really show a need
for an API change. :P

-- 
Kees Cook

  reply	other threads:[~2021-03-16 19:33 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-10 12:01 [PATCH v8 0/8] Count rlimits in each user namespace Alexey Gladkov
2021-03-10 12:01 ` Alexey Gladkov
2021-03-10 12:01 ` [PATCH v8 1/8] Increase size of ucounts to atomic_long_t Alexey Gladkov
2021-03-10 12:01   ` Alexey Gladkov
2021-03-10 12:01 ` [PATCH v8 2/8] Add a reference to ucounts for each cred Alexey Gladkov
2021-03-10 12:01   ` Alexey Gladkov
2021-03-10 12:01 ` [PATCH v8 3/8] Use atomic_t for ucounts reference counting Alexey Gladkov
2021-03-10 12:01   ` Alexey Gladkov
2021-03-10 21:14   ` Linus Torvalds
2021-03-10 21:14     ` Linus Torvalds
2021-03-15 22:02   ` Kees Cook
2021-03-15 22:02     ` Kees Cook
2021-03-15 22:19     ` Linus Torvalds
2021-03-15 22:19       ` Linus Torvalds
2021-03-16 18:49       ` Kees Cook
2021-03-16 18:49         ` Kees Cook
2021-03-16 19:26         ` Linus Torvalds
2021-03-16 19:26           ` Linus Torvalds
2021-03-16 19:32           ` Kees Cook [this message]
2021-03-16 19:32             ` Kees Cook
2021-03-10 12:01 ` [PATCH v8 4/8] Reimplement RLIMIT_NPROC on top of ucounts Alexey Gladkov
2021-03-10 12:01   ` Alexey Gladkov
2021-03-10 12:01 ` [PATCH v8 5/8] Reimplement RLIMIT_MSGQUEUE " Alexey Gladkov
2021-03-10 12:01   ` Alexey Gladkov
2021-03-10 12:01 ` [PATCH v8 6/8] Reimplement RLIMIT_SIGPENDING " Alexey Gladkov
2021-03-10 12:01   ` Alexey Gladkov
2021-03-10 12:01 ` [PATCH v8 7/8] Reimplement RLIMIT_MEMLOCK " Alexey Gladkov
2021-03-10 12:01   ` Alexey Gladkov
2021-03-10 12:01 ` [PATCH v8 8/8] kselftests: Add test to check for rlimit changes in different user namespaces Alexey Gladkov
2021-03-10 12:01   ` Alexey Gladkov

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=202103161229.75FDE42F@keescook \
    --to=keescook@chromium.org \
    --cc=akpm@linux-foundation.org \
    --cc=axboe@kernel.dk \
    --cc=containers@lists.linux-foundation.org \
    --cc=ebiederm@xmission.com \
    --cc=io-uring@vger.kernel.org \
    --cc=jannh@google.com \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=legion@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=oleg@redhat.com \
    --cc=torvalds@linux-foundation.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.