netdev - Re: [RFC][PATCH] Fix another namespace issue with devices assigned to classes

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: <AANLkTinTSQ6Ncz3FqgFHasJc2ZKfm2vaweJHUam9b-gi@mail.gmail.com>
Date:	Thu, 3 Jun 2010 11:30:20 +0200
From:	Kay Sievers <kay.sievers@...y.org>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Johannes Berg <johannes@...solutions.net>,
	Greg KH <greg@...ah.com>, netdev <netdev@...r.kernel.org>
Subject: Re: [RFC][PATCH] Fix another namespace issue with devices assigned to 
	classes

On Thu, Jun 3, 2010 at 02:53, Eric W. Biederman <ebiederm@...ssion.com> wrote:
>
> In the last painful restructuring of sysfs we created started
> creating class directories under normal devices so we could place
> devices such as network devices directly under their the hardware
> that implements them instead of in their class directories like
> /sys/class/net/.  This creation of class directories avoids the
> need to worry about namespace clonflicts if something is renamed.
>
> A special exception was made for devices that were still placed
> directly in their class directory.  Looking at how this interacts
> with the wireless network devices it appears this special exception
> is either completely unneeded or at least needs to be restricted to
> a parent device with the same class as the child device.  Certainly
> in the case of unrelated classes we very much have the possibility
> of namespace classes and we should be creating the subdirectory.

The class-glue-directories are only created between a bus-parent and
and a class device. Class devices usually don't have other class
devices as parents, that's why it wasn't done that way.

If people use class devices from other classes as parents, they should
definitely convert the class that acts as a parent to a bus, to fit
into the usual model. All that was really never meant to be used that
way. The current behavior, to not to create the glue-directory is at
least the intended one from the driver core's perspective.

What kind of classes do this, where this change would help or would be needed?

I don't mind trying if that change will work for people, I can't tell
if there are any other users doing things like this which could break
with such a change. Stuff like udev will be fine with directories
inserted, but there are many things out there, that just access their
parents attributes with ../../foo, which might no longer work when we
insert directories.

Thanks,
Kay
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html