Re: [PATCH] driver-core : get_device before create/remove sysfsfiles

From: Cornelia Huck
Date: Thu Jan 31 2008 - 04:39:59 EST


On Thu, 31 Jan 2008 09:17:18 +0800,
"Dave Young" <hidave.darkstar@xxxxxxxxx> wrote:

> On Jan 30, 2008 6:32 PM, Cornelia Huck <cornelia.huck@xxxxxxxxxx> wrote:
> > On Wed, 30 Jan 2008 09:56:25 +0800,
> > Dave Young <hidave.darkstar@xxxxxxxxx> wrote:
> >
> > > get dev reference before create/remove sysfiles, errno fixes as well.
> > >
> > > Signed-off-by: Dave Young <hidave.darkstar@xxxxxxxxx>
> > >
> > > ---
> > > drivers/base/core.c | 12 ++++++++----
> > > 1 file changed, 8 insertions(+), 4 deletions(-)
> > >
> > > diff -upr a/drivers/base/core.c b/drivers/base/core.c
> > > --- a/drivers/base/core.c 2008-01-30 09:49:56.000000000 +0800
> > > +++ b/drivers/base/core.c 2008-01-30 09:49:56.000000000 +0800
> > > @@ -414,7 +414,7 @@ struct kset *devices_kset;
> > > */
> > > int device_create_file(struct device *dev, struct device_attribute *attr)
> > > {
> > > - int error = 0;
> > > + int error = -ENODEV;
> >
> > Uhm... why?
>
> In this function :
> if (get_device(dev)) {
> do create issue
> }
> return error
>
> So IMO the initial error should be -ENODEV

If everybody can agree on returning this error in case of dev == NULL,
OK. But please don't mix changing the function's semantics with the
other changes.

>
> >
> > > if (get_device(dev)) {
> > > error = sysfs_create_file(&dev->kobj, &attr->attr);
> > > put_device(dev);
> > > @@ -442,9 +442,11 @@ void device_remove_file(struct device *d
> > > */
> > > int device_create_bin_file(struct device *dev, struct bin_attribute *attr)
> > > {
> > > - int error = -EINVAL;
> > > - if (dev)
> > > + int error = -ENODEV;
> > > + if (get_device(dev)) {
> > > error = sysfs_create_bin_file(&dev->kobj, attr);
> > > + put_device(dev);
> > > + }
> >
> > Why do we need to grab a reference here? If the calling site doesn't
> > hold unto a reference already, something is seriously broken.
>
> First, we should keep consistent with previous function "device_create_file";

I'd rather think that device_create_file() should be changed (see patch
below).

> Second, AFAIK this function mostly are called after something like device_add
> and the dev reference are not hold.

That code holds the reference acquired through device_initialize().

I think we should just get rid of those get/put games:


Driver core: Remove unneeded get_{device,driver}() calls.

Code trying to add/remove attributes must hold a reference to
the device resp. driver anyway, so let's remove those reference
count games.

Signed-off-by: Cornelia Huck <cornelia.huck@xxxxxxxxxx>

---
drivers/base/core.c | 8 ++------
drivers/base/driver.c | 9 +++------
2 files changed, 5 insertions(+), 12 deletions(-)

--- linux-2.6.orig/drivers/base/core.c
+++ linux-2.6/drivers/base/core.c
@@ -423,10 +423,8 @@ struct kset *devices_kset;
int device_create_file(struct device *dev, struct device_attribute *attr)
{
int error = 0;
- if (get_device(dev)) {
+ if (dev)
error = sysfs_create_file(&dev->kobj, &attr->attr);
- put_device(dev);
- }
return error;
}

@@ -437,10 +435,8 @@ int device_create_file(struct device *de
*/
void device_remove_file(struct device *dev, struct device_attribute *attr)
{
- if (get_device(dev)) {
+ if (dev)
sysfs_remove_file(&dev->kobj, &attr->attr);
- put_device(dev);
- }
}

/**
--- linux-2.6.orig/drivers/base/driver.c
+++ linux-2.6/drivers/base/driver.c
@@ -97,10 +97,9 @@ int driver_create_file(struct device_dri
struct driver_attribute *attr)
{
int error;
- if (get_driver(drv)) {
+ if (drv)
error = sysfs_create_file(&drv->p->kobj, &attr->attr);
- put_driver(drv);
- } else
+ else
error = -EINVAL;
return error;
}
@@ -114,10 +113,8 @@ EXPORT_SYMBOL_GPL(driver_create_file);
void driver_remove_file(struct device_driver *drv,
struct driver_attribute *attr)
{
- if (get_driver(drv)) {
+ if (drv)
sysfs_remove_file(&drv->p->kobj, &attr->attr);
- put_driver(drv);
- }
}
EXPORT_SYMBOL_GPL(driver_remove_file);

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/