On Wed, Jun 01, 2022 at 09:45:15AM -0700, Linus Torvalds wrote:
> On Wed, Jun 1, 2022 at 6:20 AM Alexey Gladkov <[email protected]> wrote:
> >
> > Dynamic memory allocation is needed to modify .data and specify the per
> > namespace parameter. The new sysctl API is allowed to get rid of the
> > need for such modification.
>
> Ok, this is looking better. That said, a few comments:
>
> >
> > diff --git a/ipc/ipc_sysctl.c b/ipc/ipc_sysctl.c
> > index ef313ecfb53a..833b670c38f3 100644
> > --- a/ipc/ipc_sysctl.c
> > +++ b/ipc/ipc_sysctl.c
> > @@ -68,26 +68,94 @@ static int proc_ipc_sem_dointvec(struct ctl_table *table, int write,
> > return ret;
> > }
> >
> > +static inline void *data_from_ns(struct ctl_context *ctx, struct ctl_table *table);
> > +
> > +static int ipc_sys_open(struct ctl_context *ctx, struct inode *inode, struct file *file)
> > +{
> > + struct ipc_namespace *ns = current->nsproxy->ipc_ns;
> > +
> > + // For now, we only allow changes in init_user_ns.
> > + if (ns->user_ns != &init_user_ns)
> > + return -EPERM;
> > +
> > +#ifdef CONFIG_CHECKPOINT_RESTORE
> > + int index = (ctx->table - ipc_sysctls);
> > +
> > + switch (index) {
> > + case IPC_SYSCTL_SEM_NEXT_ID:
> > + case IPC_SYSCTL_MSG_NEXT_ID
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/bpf/cgroup.c#n1392:
> [...]
>
> I don't think you actually even compile-tested this, because you're
> using these IPC_SYSCTL_SEM_NEXT_ID etc enums before you even declared
> them later in the same file.
I did it but without CONFIG_CHECKPOINT_RESTORE.
This is where I'm not sure who can write to ipc sysctls inside
ipc_namespace.
> > +static ssize_t ipc_sys_read(struct ctl_context *ctx, struct file *file,
> > + char *buffer, size_t *lenp, loff_t *ppos)
> > +{
> > + struct ctl_table table = *ctx->table;
> > + table.data = data_from_ns(ctx, ctx->table);
> > + return table.proc_handler(&table, 0, buffer, lenp, ppos);
> > +}
>
> Can we please fix the names and the types of this new 'ctx' structure?
>
> Yes, yes, I know the old legacy "sysctl table" is horribly named, and
> uses "ctl_table".
Sure.
> But let's just write it out. It's not some random control table for
> anything. It's a very odd and specific thing: "sysctl". Let's use the
> full name.
>
> Also, Please just make that "ctl_data" member in that "ctl_context"
> struct not just have a real name, but a real type. Make it literally
> be
>
> struct ipc_namespace *ipc_ns;
>
> and if we end up with other things wanting other pointers, just add a
> new one (or make a union if we care about the size of that allocation,
> which I don't see any reason we'd do when it's literally just like a
> couple of pointers in size).
>
> There is no reason to have some pseudo-generic "void *ctl_data" that
> makes it ambiguous and allows for type confusion and isn't
> self-documenting. I'd rather have a properly typed pointer that is
> just initialized to NULL and is not always used or needed, but always
> has a clear case for *what* it would be used for.
>
> Yes, yes, we have f_private etc for things that are really very very
> generic and have arbitrary users. But 'sysctl' is not that kind of
> truly generic use.
Yep. I made ctl_data in the same way as f_private. My idea is that if
someone needs to store more than one pointer, they can put a struct there.
But it turned out that at least now, apart from ipc_namespace, nothing is
needed.
> I wish we didn't have that silly "create a temporary ctl_table entry"
> either, and I wish it was properly named. But it's not worth the
> pointless churn to fix old bad interfaces. But the new ones should
> have better names, and try to avoid those bad old decisions.
Currently temporary ctl_table is the main strategy for handling sysctl
entries.
Perhaps it will be possible to get rid of this if we add another
get_data() that would return what is currently placed in .data in
ctl_table. I mean make getting .data dynamic.
> But yeah, I think this all is a step in the right direction. And maybe
> some of those cases and old 'ctl_table' things can be migrated to just
> using individual read() functions entirely. The whole 'ctl_table'
> model was broken, and came from the bad old days with an actual
> 'sysctl()' system call.
I'm not sure how to get rid of ctl_table since net sysctls are heavily
dependent on it.
I was wondering if it's possible to get rid of ctl_table but if it's not
possible to rewrite everything to some kind of new magic API, then keeping
two of them would be a nightmare.
Another problem is that ctl_table is being used by __cgroup_bpf_run_filter_sysctl.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/bpf/cgroup.c#n1392
> Because I think it would be lovely if people would move away from the
> 'sysctl table' approach entirely for cases where that makes sense, and
> these guys that already need special handling are very much in that
> situation.
Since you think that these patches are a step in the right direction, then
I will prepare the first version with your comments in mind.
--
Rgrds, legion
On Wed, Jun 1, 2022 at 11:25 AM Alexey Gladkov <[email protected]> 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
On Wed, Jun 01, 2022 at 11:34:18AM -0700, Linus Torvalds wrote:
> On Wed, Jun 1, 2022 at 11:25 AM Alexey Gladkov <[email protected]> wrote:
> >
> > I'm not sure how to get rid of ctl_table since net sysctls are heavily
> > dependent on it.
>
> 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.
That's a good summary of the cleanup with sysctls so I appreciate the nudges
in the right directions.
Luis