All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexey Gladkov <legion@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Containers <containers@lists.linux.dev>
Subject: Re: [GIT PULL] ucounts: Count rlimits in each user namespace
Date: Tue, 29 Jun 2021 22:20:28 +0200	[thread overview]
Message-ID: <20210629202028.gduluywejae75icj@example.org> (raw)
In-Reply-To: <CAHk-=wgcpK3XdFKJ98b_YucXbQMJMgJssAk=sQ-XUo-tyiMjVg@mail.gmail.com>

On Tue, Jun 29, 2021 at 11:07:11AM -0700, Linus Torvalds wrote:
> On Tue, Jun 29, 2021 at 10:18 AM Alexey Gladkov <legion@kernel.org> wrote:
> >
> >
> > > And why test for "ucounts" being non-NULL in
> > >
> > >                 if (ucounts && dec_rlimit_ucounts(ucounts,
> > > UCOUNT_RLIMIT_SIGPENDING, 1))
> > >                         put_ucounts(ucounts);
> > >
> > > when afaik both of those should be happy with a NULL 'ucounts' pointer
> > > (if it was NULL, we certainly already used it for the reverse
> > > operations for get_ucounts() and inc_rlimit_ucounts()..)
> >
> > The get_ucount() can theoretically return NULL. It increments the
> > reference counter and if it overflows, the function will return NULL.
> 
> .. but my point is that dec_rlimit_ucounts() and put_ucounts() should
> be fine with whatever get_ucounts() returned. No
> 
> It looks like put_ucounts() is unhappy with a NULL ucounts argument,
> but I think _that_ is what should get fixed.
> 
> I think that conceptually we should have two clear alternatives:
> 
>  (a) either "get_ucounts()" returning NULL should be an error, and we
> would have returned long before

get_ucounts() in the __sigqueue_alloc() performs the get_uid() function
but does not ignore the counter overflow. Basically get_uid() can fail in
same way as get_ucounts(), but we just ignore it.

> or
> 
>  (b) a NULL uncounts is usable, and a sequence like
> put_ucounts(get_ucounts()) should just always work.
> 
> And honestly, a lot of the other ucounts funcrtions seem to take that
> (b) approach. Example in that very function:
> 
>         ucounts = task_ucounts(t);
>         sigpending = inc_rlimit_ucounts(ucounts, UCOUNT_RLIMIT_SIGPENDING, 1);
> 
> which at no point tested for NULL or returned an error.

Waaaait. task_ucounts() is a different thing. This function only gets a
field from the task structure without any reference counting. But the
get_ucounts() is more like get_user_ns() or get_uid(), but does not ignore
counter overflow.

Earlier I tried to use refcount_t which never returns errors [1]. We
talked and you said that ignoring counter overflow errors is bad
design for this case.

> (And that also implies that the comment in dec_rlimit_ucounts() about
> "Silence compiler warning" should just go away, because it's not just
> a compiler warning, it's a required initialization).
> 
>               Linus

[1] https://lore.kernel.org/lkml/CAHk-%3dwjYOCgM%2bmKzwTZwkDDg12DdYjFFkmoFKYLim7NFmR9HBg@mail.gmail.com/

-- 
Rgrds, legion


  reply	other threads:[~2021-06-29 20:20 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-28 22:35 [GIT PULL] ucounts: Count rlimits in each user namespace Eric W. Biederman
2021-06-28 22:35 ` Eric W. Biederman
2021-06-29  3:47 ` Linus Torvalds
2021-06-29  3:47   ` Linus Torvalds
2021-06-29 15:04   ` Eric W. Biederman
2021-06-29 15:04     ` Eric W. Biederman
2021-06-29 15:51   ` Eric W. Biederman
2021-06-29 15:51     ` Eric W. Biederman
2021-06-29 16:34     ` Linus Torvalds
2021-06-29 16:34       ` Linus Torvalds
2021-06-29 16:42       ` Eric W. Biederman
2021-06-29 16:42         ` Eric W. Biederman
2021-06-29 17:09         ` Eric W. Biederman
2021-06-29 17:09           ` Eric W. Biederman
2021-07-01 16:41           ` Alexey Gladkov
2021-07-01 20:05             ` Eric W. Biederman
2021-07-01 20:05               ` Eric W. Biederman
2021-06-29 17:17   ` Alexey Gladkov
2021-06-29 18:07     ` Linus Torvalds
2021-06-29 18:07       ` Linus Torvalds
2021-06-29 20:20       ` Alexey Gladkov [this message]
2021-06-29 20:33         ` Linus Torvalds
2021-06-29 20:33           ` Linus Torvalds
2021-06-29 21:22           ` Alexey Gladkov
2021-07-02 17:54           ` [PATCH] ucounts: Fix UCOUNT_RLIMIT_SIGPENDING counter leak Alexey Gladkov
2021-07-02 22:13             ` Linus Torvalds
2021-07-02 22:13               ` Linus Torvalds
2021-07-07 16:50               ` Alexey Gladkov
2021-07-07 17:23                 ` Linus Torvalds
2021-07-07 17:23                   ` Linus Torvalds
2021-07-08 10:33                   ` [PATCH v2] " Alexey Gladkov
2021-07-08 18:44                     ` Linus Torvalds
2021-07-08 18:44                       ` Linus Torvalds
2021-07-08 11:00                   ` [PATCH] ucounts: " Alexey Gladkov
2021-06-29  3:50 ` [GIT PULL] ucounts: Count rlimits in each user namespace pr-tracker-bot

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=20210629202028.gduluywejae75icj@example.org \
    --to=legion@kernel.org \
    --cc=containers@lists.linux.dev \
    --cc=ebiederm@xmission.com \
    --cc=linux-kernel@vger.kernel.org \
    --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.