Ref-count problem in kset_find_obj?

Ref-count problem in kset_find_obj?

[Martin Schwidefsky]

Hi Pat,
looking through the sysfs code I noticed a potential problem in
kset_find_obj:

struct kobject * kset_find_obj(struct kset * kset, const char * name)
{
        struct list_head * entry;
        struct kobject * ret = NULL;

        down_read(&kset->subsys->rwsem);
        list_for_each(entry,&kset->list) {
                struct kobject * k = to_kobj(entry);
                if (!strcmp(kobject_name(k),name)) {
			ret = k;
			break;
                }
        }
        up_read(&kset->subsys->rwsem);
        return ret;
}

The reference count of the kobject to be returned is not
increased before the semaphore is released. A kobject_del/unlink
could remove the object before the called of kset_find_obj is
able to increase the reference count. This makes kset_find_obj
more or less unusable, doesn't it?

blue skies,
  Martin.

Re: Ref-count problem in kset_find_obj?

[Patrick Mochel]

> The reference count of the kobject to be returned is not
> increased before the semaphore is released. A kobject_del/unlink
> could remove the object before the called of kset_find_obj is
> able to increase the reference count. This makes kset_find_obj
> more or less unusable, doesn't it?

Yes, you're right. The function is pretty much unused, and I don't have a 
problem removing it, provided we can fix up the one user 
(arch/i386/kernel/edd.c). Unless of course, you're planning on using it..


	Pat

Re: Ref-count problem in kset_find_obj?

[Matt Domsch]

On Wed, Oct 29, 2003 at 04:24:58PM -0800, Patrick Mochel wrote:
> 
> > The reference count of the kobject to be returned is not
> > increased before the semaphore is released. A kobject_del/unlink
> > could remove the object before the called of kset_find_obj is
> > able to increase the reference count. This makes kset_find_obj
> > more or less unusable, doesn't it?
> 
> Yes, you're right. The function is pretty much unused, and I don't have a 
> problem removing it, provided we can fix up the one user 
> (arch/i386/kernel/edd.c). Unless of course, you're planning on using it..

At the moment, edd.c doesn't actually use it.  It wants to -
find_bus() is a useful concept, but I haven't proven that the scsi_bus
list only has scsi_devices on it, so that code isn't compiled in at
present.  If the scsi_bus list is clean now, then yes, I'll want to
turn it back on (after 2.6.0 is out) and will need find_bus() to be
possible.

Thanks,
Matt

-- 
Matt Domsch
Sr. Software Engineer, Lead Engineer
Dell Linux Solutions www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com

Re: Ref-count problem in kset_find_obj?

[Martin Schwidefsky]

> > Yes, you're right. The function is pretty much unused, and I don't have
a
> > problem removing it, provided we can fix up the one user
> > (arch/i386/kernel/edd.c). Unless of course, you're planning on using
it..
>
> At the moment, edd.c doesn't actually use it.  It wants to -
> find_bus() is a useful concept, but I haven't proven that the scsi_bus
> list only has scsi_devices on it, so that code isn't compiled in at
> present.  If the scsi_bus list is clean now, then yes, I'll want to
> turn it back on (after 2.6.0 is out) and will need find_bus() to be
> possible.

We don't plan to use kset_find_obj in the near future but since Matt
wants to use it, better fix it. The fix should be easy just add a
kobject_get and make the caller of kset_find_obj return the reference
again.

blue skies,
   Martin