[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 18 Jan 2021 11:14:48 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Alexey Gladkov <gladkov.alexey@...il.com>
Cc: 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>, Kees Cook <keescook@...omium.org>,
Oleg Nesterov <oleg@...hat.com>
Subject: Re: [RFC PATCH v3 1/8] Use refcount_t for ucounts reference counting
On Fri, Jan 15, 2021 at 6:59 AM Alexey Gladkov <gladkov.alexey@...il.com> wrote:
>
> @@ -152,10 +153,7 @@ static struct ucounts *get_ucounts(struct user_namespace *ns, kuid_t uid)
> ucounts = new;
> }
> }
> - if (ucounts->count == INT_MAX)
> - ucounts = NULL;
> - else
> - ucounts->count += 1;
> + refcount_inc(&ucounts->count);
> spin_unlock_irq(&ucounts_lock);
> return ucounts;
> }
This is wrong.
It used to return NULL when the count saturated.
Now it just silently saturates.
I'm not sure how many people care, but that NULL return ends up being
returned quite widely (through "inc_uncount()" and friends).
The fact that this has no commit message at all to explain what it is
doing and why is also a grounds for just NAK.
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.
