Re: patch idr-fix-a-critical-misallocation-bug.patch added to 2.6.32-stable tree

[Xiaotian Feng]

On Thu, Feb 4, 2010 at 11:56 AM, Tejun Heo <tj@xxxxxxxxxx> wrote:
> On 02/04/2010 12:46 PM, Stefan Lippers-Hollmann wrote:
>> Hi
>>
>> [ Sorry for not reporting this earlier today, while
>> Â idr-fix-a-critical-misallocation-bug was still part of queue-2.6.32, but
>> Â bisecting this (and previously net-restore-ip-source-validation.patch)
>> Â took its time. ]
>>
>> On Thursday 04 February 2010, Greg KH wrote:
>>> On Wed, Feb 03, 2010 at 08:21:39AM -0500, Eric Paris wrote:
>>>> On Wed, 2010-02-03 at 14:21 +0900, Tejun Heo wrote:
>>>>
>>>>>> Eric Paris located a bug in idr. ÂWith IDR_BITS of 6, it grows to three
>>>>>> layers when id 4096 is first allocated. ÂWhen that happens, idr wraps
>>>>>> incorrectly and searches the idr array ignoring the high bits. ÂThe
>>>>>> following test code from Eric demonstrates the bug nicely.
>>>>> ...
>>>>>> Based-on-patch-from: Eric Paris <eparis@xxxxxxxxxx>
>>>>>> Reported-by: Eric Paris <eparis@xxxxxxxxxx>
>>>>>> Signed-off-by: Tejun Heo <tj@xxxxxxxxxx>
>>>>>> Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
>>>>>> Signed-off-by: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
>>>>>> Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxx>
>>>>>
>>>>> Greg, can this wait a bit more, maybe until the next -stable release?
>>>>> The code there is very fragile and this has been broken forever so I
>>>>> think it would be better if we wait a bit more while it gets testing
>>>>> mainline.
>>
>> Just as a side note, this patch as part of the 2.6.32 stable queue (before
>> this patch was removed again) seems to break logging into KDE 4.3.4 through
>> kdm on several different systems with Intel chipsets/ graphics (kvm
>> active). X and kdm start normally, logging in shows the ksplash, which
>> quickly terminates the xsession and dumps back to kdm. Removing just this
>> patch from 2.6.32 + (previous) stable queue fixes the problem for me;
>> however 2.6.33-rc6-git3 seems to be affected as well, but freezes X,
>> instead of "just" terminating the current X session and reverting to kdm.
>>
>> While I have reports from several different intel chipsets, I can
>> personally reproduce it on an Intel D945GCLF2 mainboard:

My x86_64 box gets following messages when I'm running ltp testcase
msgctl10, and my system hangs then.
reverting this patch makes msgctl10 go through.

BUG: spinlock already unlocked on CPU#3, msgctl10/1824
 lock: ffff88021b627110, .magic: dead4ead, .owner: msgctl10/1824, .owner_cpu: 3
Pid: 1824, comm: msgctl10 Not tainted 2.6.33-rc6-git #56
Call Trace:
 [<ffffffff81225889>] spin_bug+0x9c/0xa3
 [<ffffffff812258cc>] do_raw_spin_unlock+0x3c/0x8d
 [<ffffffff814497c3>] _raw_spin_unlock+0x2b/0x2f
 [<ffffffff811cdf90>] ipc_unlock+0xe/0x15
 [<ffffffff811ce9f0>] newque+0x137/0x147
 [<ffffffff8144812a>] ? down_write+0x7a/0x81
 [<ffffffff811cd689>] ipcget+0x121/0x1a9
 [<ffffffff811ce8a5>] sys_msgget+0x55/0x59
 [<ffffffff811ce8b9>] ? newque+0x0/0x147
 [<ffffffff811ce8a9>] ? msg_security+0x0/0x10
 [<ffffffff81009bf2>] system_call_fastpath+0x16/0x1b

>
> Does this patch make any difference?

This solves my spinlock already unlock issue.

>
> diff --git a/lib/idr.c b/lib/idr.c
> index ba7d37c..a96c604 100644
> --- a/lib/idr.c
> +++ b/lib/idr.c
> @@ -140,7 +140,8 @@ static int sub_alloc(struct idr *idp, int *starting_id, struct idr_layer **pa)
> Â Â Â Âid = *starting_id;
> Ârestart:
> Â Â Â Âp = idp->top;
> - Â Â Â l = p->layer;
> + Â Â Â l = idp->layers;
> + Â Â Â pa[l--] = NULL;
> Â Â Â Âwhile (1) {
> Â Â Â Â Â Â Â Â/*
> Â Â Â Â Â Â Â Â * We run around this while until we reach the leaf node...
>
>
> --
> tejun
> --
> 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/
>
--
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/