Re: 2.6.30-rc6: Reported regressions from 2.6.29

Linus Torvalds
2009-05-17T00:02:51Z

On Sat, 16 May 2009, Rafael J. Wysocki wrote:
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13326
> Subject : Null pointer dereference in rtc-cmos driver
> Submitter : Ozan Çağlayan <ozan@pardus.org.tr>
> Date : 2009-05-14 16:16 (3 days old)
> References : http://marc.info/?l=linux-kernel&m=124231783704696&w=4

Ok, I'm of two minds on this one.

The thing that triggers it is a module that is both a module _and_
compiled in (ie the same kernel compiled twice, and the stale module kept
around). I can see how it happens, and we should react more gracefully to
it, but at the same time I can't really bring myself to care deeply.

What is going on is that the cmos-rtc.c driver does this:

#ifdef CONFIG_PNP
pnp_register_driver(&cmos_pnp_driver);
#endif

if (!cmos_rtc.dev)
retval = platform_driver_probe(&cmos_platform_driver,
cmos_platform_probe);

if (retval == 0)
return 0;

#ifdef CONFIG_PNP
pnp_unregister_driver(&cmos_pnp_driver);
#endif
return retval;

and what happens is that the pnp_register_driver fails when the module
calls it (because the built-in driver already exists under the same name):

[ 10.428691] Error: Driver 'rtc_cmos' is already registered, aborting...

but the driver doesn't really care whether that succeeded or not, but then
the platform_driver_probe fails (because the thing is already in use), so
then it ends up unregistering something that never got registered in the
first place.

I think this is strictly speaking a bug in driver_unregister(), which is
too fragile. If you unregister a drivert that wasn't registered, we
shouldn't oops.

But we could certainly do it at the rtc-cmos.c level too, and just not
unregister it if the registration failed. My gut feel is that we should
aim for the core driver helpers to be less fragile, though - we'll always
have driver bugs.

Greg?

Linus