[permalink] [raw]

Subject: [PATCH v11 3/9] Use atomic_t for ucounts reference counting

From: Alexey Gladkov <[email protected]>

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.

Now we need to use spin_lock only if we want to change the hashtable.

v10:
* Always try to put ucounts in case we cannot increase ucounts->count.
This will allow to cover the case when all consumers will return
ucounts at once.

v9:
* Use a negative value to check that the ucounts->count is close to
overflow.

Signed-off-by: Alexey Gladkov <[email protected]>
---
include/linux/user_namespace.h | 4 +--
kernel/ucount.c | 53 ++++++++++++----------------------
2 files changed, 21 insertions(+), 36 deletions(-)

diff --git a/include/linux/user_namespace.h b/include/linux/user_namespace.h
index f71b5a4a3e74..d84cc2c0b443 100644
--- a/include/linux/user_namespace.h
+++ b/include/linux/user_namespace.h
@@ -92,7 +92,7 @@ struct ucounts {
struct hlist_node node;
struct user_namespace *ns;
kuid_t uid;
- int count;
+ atomic_t count;
atomic_long_t ucount[UCOUNT_COUNTS];
};

@@ -104,7 +104,7 @@ void retire_userns_sysctls(struct user_namespace *ns);
struct ucounts *inc_ucount(struct user_namespace *ns, kuid_t uid, enum ucount_type type);
void dec_ucount(struct ucounts *ucounts, enum ucount_type type);
struct ucounts *alloc_ucounts(struct user_namespace *ns, kuid_t uid);
-struct ucounts *get_ucounts(struct ucounts *ucounts);
+struct ucounts * __must_check get_ucounts(struct ucounts *ucounts);
void put_ucounts(struct ucounts *ucounts);

#ifdef CONFIG_USER_NS
diff --git a/kernel/ucount.c b/kernel/ucount.c
index 50cc1dfb7d28..365865f368ec 100644
--- a/kernel/ucount.c
+++ b/kernel/ucount.c
@@ -11,7 +11,7 @@
struct ucounts init_ucounts = {
.ns = &init_user_ns,
.uid = GLOBAL_ROOT_UID,
- .count = 1,
+ .count = ATOMIC_INIT(1),
};

#define UCOUNTS_HASHTABLE_BITS 10
@@ -139,6 +139,15 @@ static void hlist_add_ucounts(struct ucounts *ucounts)
spin_unlock_irq(&ucounts_lock);
}

+struct ucounts *get_ucounts(struct ucounts *ucounts)
+{
+ if (ucounts && atomic_add_negative(1, &ucounts->count)) {
+ put_ucounts(ucounts);
+ ucounts = NULL;
+ }
+ return ucounts;
+}
+
struct ucounts *alloc_ucounts(struct user_namespace *ns, kuid_t uid)
{
struct hlist_head *hashent = ucounts_hashentry(ns, uid);
@@ -155,7 +164,7 @@ struct ucounts *alloc_ucounts(struct user_namespace *ns, kuid_t uid)

new->ns = ns;
new->uid = uid;
- new->count = 0;
+ atomic_set(&new->count, 1);

spin_lock_irq(&ucounts_lock);
ucounts = find_ucounts(ns, uid, hashent);
@@ -163,33 +172,12 @@ struct ucounts *alloc_ucounts(struct user_namespace *ns, kuid_t uid)
kfree(new);
} else {
hlist_add_head(&new->node, hashent);
- ucounts = new;
+ spin_unlock_irq(&ucounts_lock);
+ return new;
}
}
- if (ucounts->count == INT_MAX)
- ucounts = NULL;
- else
- ucounts->count += 1;
spin_unlock_irq(&ucounts_lock);
- return ucounts;
-}
-
-struct ucounts *get_ucounts(struct ucounts *ucounts)
-{
- unsigned long flags;
-
- if (!ucounts)
- return NULL;
-
- spin_lock_irqsave(&ucounts_lock, flags);
- if (ucounts->count == INT_MAX) {
- WARN_ONCE(1, "ucounts: counter has reached its maximum value");
- ucounts = NULL;
- } else {
- ucounts->count += 1;
- }
- spin_unlock_irqrestore(&ucounts_lock, flags);
-
+ ucounts = get_ucounts(ucounts);
return ucounts;
}

@@ -197,15 +185,12 @@ void put_ucounts(struct ucounts *ucounts)
{
unsigned long flags;

- spin_lock_irqsave(&ucounts_lock, flags);
- ucounts->count -= 1;
- if (!ucounts->count)
+ if (atomic_dec_and_test(&ucounts->count)) {
+ spin_lock_irqsave(&ucounts_lock, flags);
hlist_del_init(&ucounts->node);
- else
- ucounts = NULL;
- spin_unlock_irqrestore(&ucounts_lock, flags);
-
- kfree(ucounts);
+ spin_unlock_irqrestore(&ucounts_lock, flags);
+ kfree(ucounts);
+ }
}

static inline bool atomic_long_inc_below(atomic_long_t *v, int u)
--
2.29.3

2021-04-22 12:29:24

by Alexey Gladkov

[permalink] [raw]

> -----Original Message-----
> From: Eric W. Biederman <[email protected]>
> Sent: Tuesday, August 24, 2021 5:07 AM
> To: Alexey Gladkov <[email protected]>
> Cc: Ma, XinjianX <[email protected]>; [email protected];
> lkp <[email protected]>; [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]; [email protected]; kernel-
> [email protected]; [email protected]; linux-
> [email protected]; [email protected]; [email protected]
> Subject: [PATCH] ucounts: Fix regression preventing increasing of rlimits in
> init_user_ns
>
>
> "Ma, XinjianX" <[email protected]> reported:
>
> > When lkp team run kernel selftests, we found after these series of
> > patches, testcase mqueue: mq_perf_tests in kselftest failed with following
> message.
> >
> > # selftests: mqueue: mq_perf_tests
> > #
> > # Initial system state:
> > # Using queue path: /mq_perf_tests
> > # RLIMIT_MSGQUEUE(soft): 819200
> > # RLIMIT_MSGQUEUE(hard): 819200
> > # Maximum Message Size: 8192
> > # Maximum Queue Size: 10
> > # Nice value: 0
> > #
> > # Adjusted system state for testing:
> > # RLIMIT_MSGQUEUE(soft): (unlimited)
> > # RLIMIT_MSGQUEUE(hard): (unlimited)
> > # Maximum Message Size: 16777216
> > # Maximum Queue Size: 65530
> > # Nice value: -20
> > # Continuous mode: (disabled)
> > # CPUs to pin: 3
> > # ./mq_perf_tests: mq_open() at 296: Too many open files not ok 2
> > selftests: mqueue: mq_perf_tests # exit=1 ```
> >
> > Test env:
> > rootfs: debian-10
> > gcc version: 9
>
> After investigation the problem turned out to be that ucount_max for the
> rlimits in init_user_ns was being set to the initial rlimit value.
> The practical problem is that ucount_max provides a limit that applications
> inside the user namespace can not exceed. Which means in practice that
> rlimits that have been converted to use the ucount infrastructure were not
> able to exceend their initial rlimits.
>
> Solve this by setting the relevant values of ucount_max to RLIM_INIFINITY. A
> limit in init_user_ns is pointless so the code should allow the values to grow
> as large as possible without riscking an underflow or an overflow.
>
> As the ltp test case was a bit of a pain I have reproduced the rlimit failure and
> tested the fix with the following little C program:
> > #include <stdio.h>
> > #include <fcntl.h>
> > #include <sys/stat.h>
> > #include <mqueue.h>
> > #include <sys/time.h>
> > #include <sys/resource.h>
> > #include <errno.h>
> > #include <string.h>
> > #include <stdlib.h>
> > #include <limits.h>
> > #include <unistd.h>
> >
> > int main(int argc, char **argv)
> > {
> > struct mq_attr mq_attr;
> > struct rlimit rlim;
> > mqd_t mqd;
> > int ret;
> >
> > ret = getrlimit(RLIMIT_MSGQUEUE, &rlim);
> > if (ret != 0) {
> > fprintf(stderr, "getrlimit(RLIMIT_MSGQUEUE) failed: %s\n",
> strerror(errno));
> > exit(EXIT_FAILURE);
> > }
> > printf("RLIMIT_MSGQUEUE %lu %lu\n",
> > rlim.rlim_cur, rlim.rlim_max);
> > rlim.rlim_cur = RLIM_INFINITY;
> > rlim.rlim_max = RLIM_INFINITY;
> > ret = setrlimit(RLIMIT_MSGQUEUE, &rlim);
> > if (ret != 0) {
> > fprintf(stderr, "setrlimit(RLIMIT_MSGQUEUE, RLIM_INFINITY)
> failed: %s\n", strerror(errno));
> > exit(EXIT_FAILURE);
> > }
> >
> > memset(&mq_attr, 0, sizeof(struct mq_attr));
> > mq_attr.mq_maxmsg = 65536 - 1;
> > mq_attr.mq_msgsize = 16*1024*1024 - 1;
> >
> > mqd = mq_open("/mq_rlimit_test", O_RDONLY|O_CREAT, 0600,
> &mq_attr);
> > if (mqd == (mqd_t)-1) {
> > fprintf(stderr, "mq_open failed: %s\n", strerror(errno));
> > exit(EXIT_FAILURE);
> > }
> > ret = mq_close(mqd);
> > if (ret) {
> > fprintf(stderr, "mq_close failed; %s\n", strerror(errno));
> > exit(EXIT_FAILURE);
> > }
> >
> > return EXIT_SUCCESS;
> > }
>
> Fixes: 6e52a9f0532f ("Reimplement RLIMIT_MSGQUEUE on top of ucounts")
> Fixes: d7c9e99aee48 ("Reimplement RLIMIT_MEMLOCK on top of ucounts")
> Fixes: d64696905554 ("Reimplement RLIMIT_SIGPENDING on top of ucounts")
> Fixes: 21d1c5e386bc ("Reimplement RLIMIT_NPROC on top of ucounts")
> Reported-by: kernel test robot [email protected]
Sorry, but <> around email address is needed
Reported-by: kernel test robot <[email protected]>

> Acked-by: Alexey Gladkov <[email protected]>
> Signed-off-by: "Eric W. Biederman" <[email protected]>
> ---
>
> This is a simplified version of my previous change that I have tested and will
> push out to linux-next and then to Linus shortly.
>
> kernel/fork.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/fork.c b/kernel/fork.c index bc94b2cc5995..44f4c2d83763
> 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -828,10 +828,10 @@ void __init fork_init(void)
> for (i = 0; i < MAX_PER_NAMESPACE_UCOUNTS; i++)
> init_user_ns.ucount_max[i] = max_threads/2;
>
> - set_rlimit_ucount_max(&init_user_ns, UCOUNT_RLIMIT_NPROC,
> task_rlimit(&init_task, RLIMIT_NPROC));
> - set_rlimit_ucount_max(&init_user_ns, UCOUNT_RLIMIT_MSGQUEUE,
> task_rlimit(&init_task, RLIMIT_MSGQUEUE));
> - set_rlimit_ucount_max(&init_user_ns,
> UCOUNT_RLIMIT_SIGPENDING, task_rlimit(&init_task, RLIMIT_SIGPENDING));
> - set_rlimit_ucount_max(&init_user_ns, UCOUNT_RLIMIT_MEMLOCK,
> task_rlimit(&init_task, RLIMIT_MEMLOCK));
> + set_rlimit_ucount_max(&init_user_ns, UCOUNT_RLIMIT_NPROC,
> RLIM_INFINITY);
> + set_rlimit_ucount_max(&init_user_ns, UCOUNT_RLIMIT_MSGQUEUE,
> RLIM_INFINITY);
> + set_rlimit_ucount_max(&init_user_ns,
> UCOUNT_RLIMIT_SIGPENDING, RLIM_INFINITY);
> + set_rlimit_ucount_max(&init_user_ns, UCOUNT_RLIMIT_MEMLOCK,
> RLIM_INFINITY);
>
> #ifdef CONFIG_VMAP_STACK
> cpuhp_setup_state(CPUHP_BP_PREPARE_DYN,
> "fork:vm_stack_cache",
> --
> 2.20.1

2021-08-24 03:28:14

by Eric W. Biederman

[permalink] [raw]

Subject: Re: [PATCH] ucounts: Fix regression preventing increasing of rlimits in init_user_ns

"Ma, XinjianX" <[email protected]> writes:

>> -----Original Message-----
>> From: Eric W. Biederman <[email protected]>
>> ...
>> Reported-by: kernel test robot [email protected]
> Sorry, but <> around email address is needed
> Reported-by: kernel test robot <[email protected]>

The change is already tested and pushed out so I really don't want to
mess with it. Especially as I am aiming to send it to Linus on
Wednesday after it has had a chance to pass through linux-next and
whatever automated tests are there.

What does copying and pasting the Reported-by: tag as included in
your original report cause to break?

At this point I suspect that the danger of fat fingering something
far outweighs whatever benefits might be gained by surrounding the
email address with <> marks.

Eric