Re: [PATCH 10/11] avoid kobject name conflict with different namespaces

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

Greg KH <gregkh@suse.de> writes:

> On Wed, May 07, 2008 at 11:49:19AM -0700, Eric W. Biederman wrote:
>> Unless there is another path I think placing an additional pointer in
>> kobj_type so we can find it through ktype is the simplest solution.
>> Although using the kset is also sane.
>
> Ick, ick, ick :)
>
>> The easiest and most trivially correct thing to do would be to simply
>> remove the unnecessary check from kobject_rename.  We perform the
>> check at the upper levels in the network anyway.  And kobject_rename
>> is only used by the network stack.
>
> Wireless uses it also for some things, and it requires that it fail if a
> duplicate is found.  I thought that s390 also used it, but I don't see
> that usage in the tree anymore, perhaps they switched to something else.

Looking at this a little further kobject_rename is a complete noop
when sysfs support is not compiled in.  That is the kobject does not
get renamed, even if the higher level objects do.

This makes the wireless dependency on an error code from kobject_rename
completely bogus as the kobject layer is not prepared to give any kind of
reliable result, and it makes kobject_rename completely bogus if sysfs
support is not compiled in.

Further there is no locking to guarantee renames are atomic
or mutually exclusive at the kobject level.

With no locking and code that does nothing in the absence of sysfs
attempting to check renames for validity at the kobject level (when
renames don't happen at the kobject level) is totally bogus.

Since renames don't happen at the kobject level checking them for
sanity at the kobject level makes no sense.

Eric