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: <CAK-6q+hCTSgODtBOXJ1NvafmMszdxk0V3aj6t3LWQ9B0BDbtRw@mail.gmail.com>
Date: Mon, 15 Jul 2024 12:57:30 -0400
From: Alexander Aring <aahringo@...hat.com>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: rafael@...nel.org, 
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, gfs2 <gfs2@...ts.linux.dev>, 
	David Teigland <teigland@...hat.com>
Subject: Re: udev kset_create_and_add() with own struct kobj_type?

Hi,

On Mon, Jul 15, 2024 at 11:33 AM Greg KH <gregkh@...uxfoundation.org> wrote:
>
> On Mon, Jul 15, 2024 at 11:27:00AM -0400, Alexander Aring wrote:
> > Hi,
> >
> > I am currently implementing namespace support into the fs/dlm
> > subsystem. The DLM subsystem uses kset_create_and_add("dlm",
> > &dlm_uevent_ops, kernel_kobj); to create the "dlm" sysfs directory.
> > Underneath it creates for each lockspace a subdirectory using
> > kobject_init_and_add() with a non-static name and being known during
> > runtime.
> >
> > Now I want to add namespace support and need to change the "default"
> > kset->kobj.ktype = &kset_ktype; that is set by
> > kset_create_and_add()->kset_create() to my own kobj_type because I
> > need to implement a different ".child_ns_type" callback before
> > kset_register() is called.
> >
> > So kset_create_and_add() does not allow me to add my own
> > ".child_ns_type" callback for the kset that is required for me to have
> > my sysfs "kernel/dlm" directory separated by each net-namespace
> > without breaking any backwards compatibility.
>
> I don't understand, what "backwards compatibility" is happening here?
>

The DLM sysfs udev directory for kobjects begins in
"/sys/kernel/dlm/", that is the created kset by kset_create_and_add().
Then a lot of per lockspace kobject directories are created by
kobject_init_and_add() with a name known during runtime only.
I cannot simply do a "/sys/kernel/dlm/lockspaces/" and have
"lockspaces" separated by namespaces, it needs to be "dlm" as user
space assume a specific directory structure in "/sys/kernel/dlm" and
interprets it and we want to have lockspaces separated per namespace.

> > My current solution is that I mostly copy&pasted the code of
> > kset_create_and_add()/kset_create() to have a way to tell my own
> > struct kobj_type that contains the implemented my own ".child_ns_type"
> > callback.
>
> Ick.
>
> > I am writing this mail to get some advice on what I can do here
> > without doing the copy&pasted code?
> > Add a parameter to kset_create_and_add() that allows me to set an
> > "struct kobj_type"?
> > Introducing a new function that does allow me to set the new parameter
> > (I probably like that because then I don't need to update all other
> > users)?
>
> A new function would be ok, but I hate it how filesystems have to use

I will try this out. Thank you.

> "raw" kobjects and the like all the time.  It's rough, sorry.
>

DLM "Distributed Lock Manager" is a networking subsystem but as there
are mostly in-kernel filesystem users (gfs2, ocfs2) it is currently
part of "fs/".
The plan is to separate DLM lockspaces per net-namespace as each
separation acts like a "network entity" (node) that is required anyway
for each DLM socket handling.

> Also, I didn't think sysfs namespaces worked for anything except
> networking stuff.  Are you sure you really need this?  Where is your
> "namespace" defined at?
>

It is networking but I will not lie that at the end users of DLM e.g.
the cluster file system gfs2 is required to separate their sysfs
directly the same way as DLM is doing here as each mount is on a per
"network entity" (cluster node) basis.

It will be an experimental support in the first place to use it for
testing/developing (not required to synchronize traces over the
network) and scale testing (testing on a limited resource machine a
lockspace with 1000 of nodes instead of having 1000 VMs). The scale
part is important for us to make DLM ready to handle a lot of node
members to handle future use-cases.

I hope that this "justify" here the use of net namespaces in udev.

- Alex


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ