Messages in this thread | | | Date | Sun, 17 May 2009 08:33:46 -0700 | From | Greg KH <> | Subject | Re: 2.6.30-rc6: Reported regressions from 2.6.29 |
| |
On Sat, May 16, 2009 at 07:13:59PM -0700, Linus Torvalds wrote: > > > On Sun, 17 May 2009, Kay Sievers wrote: > > > > This makes the oops in the driver-core, caused by the rtc driver > > unregister, go away. The original issue is also fixed in the rtc driver > > itself. > > I don't think this is sufficient. > > > --- a/drivers/base/driver.c > > +++ b/drivers/base/driver.c > > @@ -257,6 +257,8 @@ EXPORT_SYMBOL_GPL(driver_register); > > */ > > void driver_unregister(struct device_driver *drv) > > { > > + if (!drv || !drv->p) > > + return; > > driver_remove_groups(drv, drv->groups); > > bus_remove_driver(drv); > > } > > Ok, fine so far, but look at "driver_register()". > > It will set drv->p, but then not unset it if it fails! (For a certain > class of failures) > > So for a certain failure pattern, drv->p will point to some stale value. > Should we not clear drv->p in the "out_unregister" patch? > > To confuse the thing more, there are actually "half-way failures" that > _succeed_ in driver registration, but then return an error code. See that > whole > > > kobject_uevent(&priv->kobj, KOBJ_ADD); > return error; > > case in the "success" path driver_register(). We may return an error > despite the fact that we actually attached the driver to bus, but > "add_bind_files()" failed. A caller would be understandable very unhappy. > > So I suspect we should do something like the appended (in addition to your > patch). Comments?
That looks good. I'll add the WARN_ON that Ingo pointed out, and merge this with Kay's patch. Give me a few hours to wake up...
thanks,
greg k-h
| |