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

[ebiederm@xmission.com (Eric W. Biederman)]

Kay Sievers <kay.sievers@vrfy.org> writes:

> On Thu, Jun 3, 2010 at 02:53, Eric W. Biederman <ebiederm@xmission.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.

To the best of my knowledge we are talking a very limited number of
real world cases.

The driver in particular that causes problems is mac80211_hwsim. It
winds up placing network devices in a directory that isn't prepared to
take network namespace tagged members, with the result that when the
module is removed we don't delete the symlinks from /sys/class/net/.
I see no reason to believe we are free of possible namespace conflicts
either, which is why I suggested the patch.

From my perspective not creating the directory in some weird corner case that
appears to practically to never happen looks like an ugly nasty special case.

If the solution winds up being converting mac80211_hwsim to using a
bus instead of a class that seems reasonable to me as well.  More code
in one place to remove the chance of problems elsewhere.

Eric