Re: oops in bttv

[Andrew Morton]

On Wed, 12 Jul 2006 22:24:07 -0700
"Randy.Dunlap" <rdunlap@xxxxxxxxxxxx> wrote:

> > > The class_dev is created like this, in video_register_device():
> > > 
> > >         memset(&vfd->class_dev, 0x00, sizeof(vfd->class_dev));
> > >         if (vfd->dev)
> > >                 vfd->class_dev.dev = vfd->dev;
> > >         vfd->class_dev.class       = &video_class;
> > >         vfd->class_dev.devt        = MKDEV(VIDEO_MAJOR, vfd->minor);
> > >         sprintf(vfd->class_dev.class_id, "%s%d", name_base, i - base);
> > >         class_device_register(&vfd->class_dev);
> > >         class_device_create_file(&vfd->class_dev,
> > >                                 &class_device_attr_name);
> > > 
> > > so it looks like class_device_register() is putting the 1 into the dentry?
> > > Culprit looks to be class_device_add() in that case.
> > 
> > Perhaps we should check the return value of class_device_register() to
> > verify that nothing bad happened there?  A dentry of 1 is very odd.
> 
> Yes.  We are in the process of adding such checks.
> Join the fun.

Chuck got about as far through this as I did.  Yes, I'm suspecting an
earlier uncaught error of some form.  The videodev changes since 2.6.17 are
small and look to be unrelated.  I'd be suspecting preexisting videodev
bugs which have been exposed by sysfs/driver-model changes.  But it's very
hard to tell.

Going through and adding 1000 missing check-error-then-recover instances is
the ideal approach, but I suspect that leaving callers as-is and blurting a
message from the driver core when some of these things fail might get us
what we need.  But right now we have neither, and we see the result.
-
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/