[lkml]   [2009]   [May]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 2.6.30-rc6: Reported regressions from 2.6.29

On Sat, 16 May 2009, Rafael J. Wysocki wrote:
> Bug-Entry :
> Subject : Null pointer dereference in rtc-cmos driver
> Submitter : Ozan Çağlayan <>
> Date : 2009-05-14 16:16 (3 days old)
> References :

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:


if (!
retval = platform_driver_probe(&cmos_platform_driver,

if (retval == 0)
return 0;

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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2009-10-18 23:28    [W:0.350 / U:1.872 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site