Messages in this thread | | | From | (Eric W. Biederman) | Date | Thu, 08 May 2008 12:25:18 -0700 | Subject | Re: [PATCH 10/11] avoid kobject name conflict with different namespaces |
| |
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
| |