Re: 2.6.16-rc1-mm1

[Andrew Morton <akpm@osdl.org>]

Reuben Farrelly <reuben-lkml@reub.net> wrote:
>
> My box came up first time lucky on this release, but I got a new oops:
> 
>  NET: Registered protocol family 1
>  NET: Registered protocol family 17
>  BUG: swapper/1, active lock [b19e6428(b19e6400-b19e6600)] freed!
>    [<b01040d1>] show_trace+0xd/0xf
>    [<b0104172>] dump_stack+0x17/0x19
>    [<b0131c6d>] mutex_debug_check_no_locks_freed+0xff/0x18e
>    [<b01544b3>] kfree+0x34/0x6a
>    [<b02a6109>] cpufreq_add_dev+0x127/0x379
>    [<b023abcb>] sysdev_driver_register+0x70/0xb0
>    [<b02a67df>] cpufreq_register_driver+0x68/0xfe
>    [<b03cc19d>] acpi_cpufreq_init+0xd/0xf
>    [<b01003cc>] init+0xff/0x325
>    [<b0100d25>] kernel_thread_helper+0x5/0xb
>    [b19e6428] {cpufreq_add_dev}
>  .. held by:           swapper:    1 [efe14ab0, 115]
>  ... acquired at:               cpufreq_add_dev+0x9d/0x379
>  p4-clockmod: P4/Xeon(TM) CPU On-Demand Clock Modulation available

Well yes, that code is kfree()ing a locked mutex.  It's somewhat weird to
take a lock on a still-private object but whatever.  The code's legal
enough.


--- devel/drivers/cpufreq/cpufreq.c~cpufreq-mutex-locking-fix	2006-01-18 03:25:33.000000000 -0800
+++ devel-akpm/drivers/cpufreq/cpufreq.c	2006-01-18 03:25:55.000000000 -0800
@@ -674,6 +674,7 @@ err_out_driver_exit:
 		cpufreq_driver->exit(policy);
 
 err_out:
+	mutex_unlock(&policy->lock);
 	kfree(policy);
 
 nomem_out:
_