[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wgBeQafNgw6DNUwM4vvw4snb83Tb65m_QH9XSic2JSJaQ@mail.gmail.com>
Date: Wed, 1 Jun 2022 11:34:18 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Alexey Gladkov <legion@...nel.org>
Cc: LKML <linux-kernel@...r.kernel.org>,
"Eric W . Biederman" <ebiederm@...ssion.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Christian Brauner <brauner@...nel.org>,
Iurii Zaikin <yzaikin@...gle.com>,
Kees Cook <keescook@...omium.org>,
Linux Containers <containers@...ts.linux.dev>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
Luis Chamberlain <mcgrof@...nel.org>,
Vasily Averin <vvs@...tuozzo.com>
Subject: Re: [RFC PATCH 2/4] sysctl: ipc: Do not use dynamic memory
On Wed, Jun 1, 2022 at 11:25 AM Alexey Gladkov <legion@...nel.org> wrote:
>
> I'm not sure how to get rid of ctl_table since net sysctls are heavily
> dependent on it.
I don't actually think it's worth getting rid of entirely, because
there's just a lot of simple cases where it "JustWorks(tm)" and having
just that table entry describe all the semantics is not wrong at all.
The name may suck, but hey, it's not a big deal. Changing it now would
be more pain than it's worth.
No, I was more thinking that things that already need more
infrastructure than that simple static ctl_table entry might be better
off trying to migrate to your new "proper read op" model, and having
more of that dynamic behavior in the read op.
The whole "create dynamic ctl_table entries on the fly" model works,
but it's kind of ugly.
Anyway, I think all of this is "I think there is more room for cleanup
in this area", and maybe we'll never have enough motivation to
actually do that.
Your patches seem to fix the extant issue with the ipc namespace, and
the truly disgusting parts (although maybe there are other truly
disgusting things hiding - I didn't go look for them).
Linus
Powered by blists - more mailing lists