linux-kernel - Re: [tip:timers/core] [posix] 1535cb8028: stress-ng.epoll.ops_per

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANn89iJvxYsF0Y9jH+Oa2=akrydR8qbWAMbz_S6YZQMSe=2QWQ@mail.gmail.com>
Date: Thu, 27 Mar 2025 12:37:48 +0100
From: Eric Dumazet <edumazet@...gle.com>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Mateusz Guzik <mjguzik@...il.com>, kernel test robot <oliver.sang@...el.com>, oe-lkp@...ts.linux.dev, 
	lkp@...el.com, linux-kernel@...r.kernel.org, x86@...nel.org, 
	Benjamin Segall <bsegall@...gle.com>, Frederic Weisbecker <frederic@...nel.org>
Subject: Re: [tip:timers/core] [posix] 1535cb8028: stress-ng.epoll.ops_per_sec
 36.2% regression

On Thu, Mar 27, 2025 at 11:50 AM Thomas Gleixner <tglx@...utronix.de> wrote:
>
> On Thu, Mar 27 2025 at 10:11, Eric Dumazet wrote:
> > On Thu, Mar 27, 2025 at 9:26 AM Eric Dumazet <edumazet@...gle.com> wrote:
> >
> >> We could place all these atomic fields in separate cache lines,
> >> to keep read-only fields shared as much as possible.
> >>
> >
> > Following one-liner seems good enough to separate the 4 atomics used
> > to control/limit
> >
> > UCOUNT_RLIMIT_NPROC, UCOUNT_RLIMIT_MSGQUEUE, UCOUNT_RLIMIT_SIGPENDING,
> > UCOUNT_RLIMIT_MEMLOCK,
> >
> >
> > diff --git a/include/linux/user_namespace.h b/include/linux/user_namespace.h
> > index 7183e5aca282..6cc3fbec3632 100644
> > --- a/include/linux/user_namespace.h
> > +++ b/include/linux/user_namespace.h
> > @@ -120,7 +120,7 @@ struct ucounts {
> >         kuid_t uid;
> >         atomic_t count;
> >         atomic_long_t ucount[UCOUNT_COUNTS];
> > -       atomic_long_t rlimit[UCOUNT_RLIMIT_COUNTS];
> > +       atomic_long_t ____cacheline_aligned_in_smp rlimit[UCOUNT_RLIMIT_COUNTS];
> >  };
>
> Cute. How much bloat does it cause?

This would expand 'struct ucounts' by 192 bytes on x86, if the patch
was actually working :)

Note sure if it is feasible without something more intrusive like

diff --git a/include/linux/user_namespace.h b/include/linux/user_namespace.h
index 7183e5aca282..3513df720430 100644
--- a/include/linux/user_namespace.h
+++ b/include/linux/user_namespace.h
@@ -120,7 +120,10 @@ struct ucounts {
        kuid_t uid;
        atomic_t count;
        atomic_long_t ucount[UCOUNT_COUNTS];
-       atomic_long_t rlimit[UCOUNT_RLIMIT_COUNTS];
+
+       struct {
+               atomic_long_t ____cacheline_aligned_in_smp val;
+       } rlimit[UCOUNT_RLIMIT_COUNTS];
 };

 extern struct user_namespace init_user_ns;
@@ -136,7 +139,7 @@ void put_ucounts(struct ucounts *ucounts);

 static inline long get_rlimit_value(struct ucounts *ucounts, enum
rlimit_type type)
 {
-       return atomic_long_read(&ucounts->rlimit[type]);
+       return atomic_long_read(&ucounts->rlimit[type].val);
 }

 long inc_rlimit_ucounts(struct ucounts *ucounts, enum rlimit_type
type, long v);
diff --git a/kernel/ucount.c b/kernel/ucount.c
index 86c5f1c0bad9..0cd5498890f8 100644
--- a/kernel/ucount.c
+++ b/kernel/ucount.c
@@ -266,7 +266,7 @@ long inc_rlimit_ucounts(struct ucounts *ucounts,
enum rlimit_type type, long v)
        long ret = 0;

        for (iter = ucounts; iter; iter = iter->ns->ucounts) {
-               long new = atomic_long_add_return(v, &iter->rlimit[type]);
+               long new = atomic_long_add_return(v, &iter->rlimit[type].val);
                if (new < 0 || new > max)
                        ret = LONG_MAX;
                else if (iter == ucounts)
@@ -281,7 +281,7 @@ bool dec_rlimit_ucounts(struct ucounts *ucounts,
enum rlimit_type type, long v)
        struct ucounts *iter;
        long new = -1; /* Silence compiler warning */
        for (iter = ucounts; iter; iter = iter->ns->ucounts) {
-               long dec = atomic_long_sub_return(v, &iter->rlimit[type]);
+               long dec = atomic_long_sub_return(v, &iter->rlimit[type].val);
                WARN_ON_ONCE(dec < 0);
                if (iter == ucounts)
                        new = dec;
@@ -294,7 +294,7 @@ static void do_dec_rlimit_put_ucounts(struct
ucounts *ucounts,
 {
        struct ucounts *iter, *next;
        for (iter = ucounts; iter != last; iter = next) {
-               long dec = atomic_long_sub_return(1, &iter->rlimit[type]);
+               long dec = atomic_long_sub_return(1, &iter->rlimit[type].val);
                WARN_ON_ONCE(dec < 0);
                next = iter->ns->ucounts;
                if (dec == 0)
@@ -316,7 +316,7 @@ long inc_rlimit_get_ucounts(struct ucounts
*ucounts, enum rlimit_type type,
        long dec, ret = 0;

        for (iter = ucounts; iter; iter = iter->ns->ucounts) {
-               long new = atomic_long_add_return(1, &iter->rlimit[type]);
+               long new = atomic_long_add_return(1, &iter->rlimit[type].val);
                if (new < 0 || new > max)
                        goto dec_unwind;
                if (iter == ucounts)
@@ -334,7 +334,7 @@ long inc_rlimit_get_ucounts(struct ucounts
*ucounts, enum rlimit_type type,
        }
        return ret;
 dec_unwind:
-       dec = atomic_long_sub_return(1, &iter->rlimit[type]);
+       dec = atomic_long_sub_return(1, &iter->rlimit[type].val);
        WARN_ON_ONCE(dec < 0);
        do_dec_rlimit_put_ucounts(ucounts, iter, type);
        return 0;