public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* Re: patch idr-fix-a-critical-misallocation-bug.patch added to 2.6.32-stable tree
       [not found]   ` <20100203233720.GA28271@suse.de>
@ 2010-02-04  3:46     ` Stefan Lippers-Hollmann
  2010-02-04  3:56       ` Tejun Heo
  0 siblings, 1 reply; 6+ messages in thread
From: Stefan Lippers-Hollmann @ 2010-02-04  3:46 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-kernel, Eric Paris, Tejun Heo, akpm, torvalds, stable

[-- Attachment #1: Type: Text/Plain, Size: 9715 bytes --]

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@redhat.com>
> > > > Reported-by: Eric Paris <eparis@redhat.com>
> > > > Signed-off-by: Tejun Heo <tj@kernel.org>
> > > > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> > > > Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> > > > Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> > > 
> > > 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:

00:00.0 Host bridge [0600]: Intel Corporation 82945G/GZ/P/PL Memory Controller Hub [8086:2770] (rev 02)                                                                                           
00:02.0 VGA compatible controller [0300]: Intel Corporation 82945G/GZ Integrated Graphics Controller [8086:2772] (rev 02)                                                                         
00:1b.0 Audio device [0403]: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller [8086:27d8] (rev 01)                                                                         
00:1c.0 PCI bridge [0604]: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 [8086:27d0] (rev 01)                                                                                         
00:1c.2 PCI bridge [0604]: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 [8086:27d4] (rev 01)                                                                                         
00:1c.3 PCI bridge [0604]: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 [8086:27d6] (rev 01)                                                                                         
00:1d.0 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 [8086:27c8] (rev 01)
00:1d.1 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 [8086:27c9] (rev 01)
00:1d.2 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 [8086:27ca] (rev 01)
00:1d.3 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 [8086:27cb] (rev 01)
00:1d.7 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller [8086:27cc] (rev 01)
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev e1)
00:1f.0 ISA bridge [0601]: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface Bridge [8086:27b8] (rev 01)
00:1f.1 IDE interface [0101]: Intel Corporation 82801G (ICH7 Family) IDE Controller [8086:27df] (rev 01)
00:1f.2 IDE interface [0101]: Intel Corporation 82801GB/GR/GH (ICH7 Family) SATA IDE Controller [8086:27c0] (rev 01)
00:1f.3 SMBus [0c05]: Intel Corporation 82801G (ICH7 Family) SMBus Controller [8086:27da] (rev 01)
01:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168] (rev 02)

===
[ the following might of course be unrelated ]
Oops captured with 2.6.33-rc6-git3 (X and kdm start up without problems, 
but freezes during ksplash - the system remains operationable through ssh):

[drm:i915_gem_do_execbuffer] *ERROR* Invalid object handle 1073741824 at index 23                
BUG: unable to handle kernel paging request at ffffffff00000080                                  
IP: [<ffffffffa00951af>] i915_gem_do_execbuffer+0x79f/0x1370 [i915]                              
PGD 14c0067 PUD 0                                                                                
Oops: 0000 [#1] PREEMPT SMP                                                                      
last sysfs file: /sys/devices/virtual/sound/timer/uevent                                         
CPU 0                                                                                            
Pid: 1846, comm: Xorg Tainted: G        W  2.6.33-rc6-sidux-amd64 #1 D945GCLF2/                  
RIP: 0010:[<ffffffffa00951af>]  [<ffffffffa00951af>] i915_gem_do_execbuffer+0x79f/0x1370 [i915]  
RSP: 0018:ffff88007c49fbf8  EFLAGS: 00010286                                                     
RAX: ffff88007e80aac0 RBX: 00000000fffffff7 RCX: 000000000000001e                                
RDX: ffffffff00000000 RSI: ffffffffa0042710 RDI: ffff88007e162a80                                
RBP: 0000000000000018 R08: 0000000000000001 R09: 0000000000000020                                
R10: 0000000000000000 R11: 000000000000006e R12: ffff88007e80aa00                                
R13: ffff88007c49fd18 R14: ffff88007e80aa00 R15: ffff88007c49fd18                                
FS:  00007f5bf591d790(0000) GS:ffff880001800000(0000) knlGS:0000000000000000                     
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033                                                
CR2: ffffffff00000080 CR3: 000000007c480000 CR4: 00000000000006f0                                
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000                                
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400                                
Process Xorg (pid: 1846, threadinfo ffff88007c49e000, task ffff88007c4fd280)                     
Stack:                                                                                           
 ffff88007bebdb80 0000000000000000 ffff88007bebde18 ffffffff8135139b                             
<0> ffff88007f002dc0 ffff880000000040 fffffff57f35a800 ffff88007e2f7800                          
<0> 0000000000001000 ffff88007c49fd48 ffff88007e80aa00 ffff88007e2f6000                          
Call Trace:                                                                                      
 [<ffffffff8135139b>] ? unix_stream_recvmsg+0x28b/0x620
 [<ffffffffa0095fa0>] ? i915_gem_execbuffer+0x0/0x410 [i915]
 [<ffffffffa00961b0>] ? i915_gem_execbuffer+0x210/0x410 [i915]
 [<ffffffffa00904d5>] ? i915_gem_sw_finish_ioctl+0x95/0xd0 [i915]
 [<ffffffffa0040958>] ? drm_ioctl+0x308/0x440 [drm]
 [<ffffffffa0095fa0>] ? i915_gem_execbuffer+0x0/0x410 [i915]
 [<ffffffff8111ef2f>] ? do_sync_read+0xbf/0x100
 [<ffffffff81071924>] ? bit_waitqueue+0x14/0xc0
 [<ffffffff8112eed5>] ? vfs_ioctl+0x35/0xd0
 [<ffffffff8112f098>] ? do_vfs_ioctl+0x88/0x570
 [<ffffffff810566b3>] ? do_setitimer+0x1c3/0x240
 [<ffffffff8112f600>] ? sys_ioctl+0x80/0xa0
 [<ffffffff8100a002>] ? system_call_fastpath+0x16/0x1b
Code: eb 48 8b 74 24 68 44 8b 4e 08 45 85 c9 74 4a 4c 8b 64 24 50 31 ed 49 89 f5 0f 1f 00 48 63 c5 49 8d 04 c4 48 8b 10 48 85 d2 74 25 <48> 8b 92 80 00 00 00 c7 82 a0 00 00 00 00 00 00 00 48 8b 38 48
RIP  [<ffffffffa00951af>] i915_gem_do_execbuffer+0x79f/0x1370 [i915]
 RSP <ffff88007c49fbf8>
CR2: ffffffff00000080
---[ end trace 88853e816bdbf457 ]---

I will test 2.6.33 HEAD with idr-fix-a-critical-misallocation-bug.patch
reverted when I get home tonight (UTC+1), I'm likely not able to respond 
before that either.

> > I'm ok with that as well.  inotify should not be able to trip up on this
> > condition any more thanks to other changes to inotify.
> 
> Ok, I've now dropped it.
> 
> thanks,
> 
> greg k-h

Regards
	Stefan Lippers-Hollmann

Post scriptum: 
Xorg.0.log.gz, kdm.log.gz and xsession errors.gz are taken from 
2.6.32.7+queue-2.6.32, including idr-fix-a-critical-misallocation-bug.patch

system:	up to date Debian sid/ unstable
		ii  hal                                                 0.5.14-2                   Hardware Abstraction Layer
		ii  libdrm-intel1                                       2.4.17-1                   Userspace interface to intel-specific kernel DRM serv
		ii  libdrm2                                             2.4.17-1                   Userspace interface to kernel DRM services -- runtime
		ii  libhal-storage1                                     0.5.14-2                   Hardware Abstraction Layer - shared library for stora
		ii  libhal1                                             0.5.14-2                   Hardware Abstraction Layer - shared library
		ii  xserver-xorg-core                                   2:1.7.4-2                  Xorg X server - core server
		ii  xserver-xorg-video-intel                            2:2.9.1-2                  X.Org X server -- Intel i8xx, i9xx display driver

[-- Attachment #2: dmesg-2.6.32.7+queue-2.6.32-EXcluding-idr-working.gz --]
[-- Type: application/x-gzip, Size: 1638 bytes --]

[-- Attachment #3: Xorg.0.log.gz --]
[-- Type: application/x-gzip, Size: 5290 bytes --]

[-- Attachment #4: dmesg-2.6.32.7+queue-2.6.32-including-idr.gz --]
[-- Type: application/x-gzip, Size: 9050 bytes --]

[-- Attachment #5: dmesg-2.6.33-rc6-git3.gz --]
[-- Type: application/x-gzip, Size: 10624 bytes --]

[-- Attachment #6: kdm.log.gz --]
[-- Type: application/x-gzip, Size: 1346 bytes --]

[-- Attachment #7: xsession-errors.gz --]
[-- Type: application/x-gzip, Size: 591 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: patch idr-fix-a-critical-misallocation-bug.patch added to 2.6.32-stable tree
  2010-02-04  3:46     ` patch idr-fix-a-critical-misallocation-bug.patch added to 2.6.32-stable tree Stefan Lippers-Hollmann
@ 2010-02-04  3:56       ` Tejun Heo
  2010-02-04  8:36         ` Xiaotian Feng
  2010-02-04 15:41         ` Stefan Lippers-Hollmann
  0 siblings, 2 replies; 6+ messages in thread
From: Tejun Heo @ 2010-02-04  3:56 UTC (permalink / raw)
  To: Stefan Lippers-Hollmann
  Cc: Greg KH, linux-kernel, Eric Paris, akpm, torvalds, stable

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@redhat.com>
>>>>> Reported-by: Eric Paris <eparis@redhat.com>
>>>>> Signed-off-by: Tejun Heo <tj@kernel.org>
>>>>> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>>>>> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>>>>> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
>>>>
>>>> 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:

Does this patch make any difference?

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

^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: patch idr-fix-a-critical-misallocation-bug.patch added to  2.6.32-stable tree
  2010-02-04  3:56       ` Tejun Heo
@ 2010-02-04  8:36         ` Xiaotian Feng
  2010-02-04 15:41         ` Stefan Lippers-Hollmann
  1 sibling, 0 replies; 6+ messages in thread
From: Xiaotian Feng @ 2010-02-04  8:36 UTC (permalink / raw)
  To: Tejun Heo
  Cc: Stefan Lippers-Hollmann, Greg KH, linux-kernel, Eric Paris, akpm,
	torvalds, stable

On Thu, Feb 4, 2010 at 11:56 AM, Tejun Heo <tj@kernel.org> 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@redhat.com>
>>>>>> Reported-by: Eric Paris <eparis@redhat.com>
>>>>>> Signed-off-by: Tejun Heo <tj@kernel.org>
>>>>>> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>>>>>> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>>>>>> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
>>>>>
>>>>> 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: patch idr-fix-a-critical-misallocation-bug.patch added to 2.6.32-stable tree
  2010-02-04  3:56       ` Tejun Heo
  2010-02-04  8:36         ` Xiaotian Feng
@ 2010-02-04 15:41         ` Stefan Lippers-Hollmann
  2010-02-11  8:51           ` Tejun Heo
  1 sibling, 1 reply; 6+ messages in thread
From: Stefan Lippers-Hollmann @ 2010-02-04 15:41 UTC (permalink / raw)
  To: Tejun Heo; +Cc: Greg KH, linux-kernel, Eric Paris, akpm, torvalds, stable

Hi

On Thursday 04 February 2010, Tejun Heo wrote:
> On 02/04/2010 12:46 PM, Stefan Lippers-Hollmann wrote:
[...]
> > 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.
[...]
> >>>> 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:
> 
> Does this patch make any difference?

Unfortunately I don't see any change, applied to queue-2.6.32 and on top of
idr-fix-a-critical-misallocation-bug.patch, KDE 4.3.4 still terminates and 
dumps me back to kdm. Applied on top of 2.6.33-rc6-git4 it still continues 
to freeze X during ksplash and spews the same oops message as before:

[drm:i915_gem_do_execbuffer] *ERROR* Invalid object handle 1073741824 at index 19                
BUG: unable to handle kernel paging request at ffffffff00000080                                  
IP: [<ffffffffa00951af>] i915_gem_do_execbuffer+0x79f/0x1370 [i915]                              
PGD 14c0067 PUD 0                                                                                
Oops: 0000 [#1] PREEMPT SMP                                                                      
last sysfs file: /sys/devices/virtual/sound/timer/uevent                                         
CPU 2                                                                                            
Pid: 1857, comm: Xorg Tainted: G        W  2.6.33-rc6-sidux-amd64 #1 D945GCLF2/                  
RIP: 0010:[<ffffffffa00951af>]  [<ffffffffa00951af>] i915_gem_do_execbuffer+0x79f/0x1370 [i915]  
RSP: 0018:ffff880037659bf8  EFLAGS: 00010286                                                     
RAX: ffff88007e3a68c0 RBX: 00000000fffffff7 RCX: 000000000000001e                                
RDX: ffffffff00000000 RSI: ffffffffa0042710 RDI: ffff88007d6d9cc0                                
RBP: 0000000000000018 R08: 0000000000000001 R09: 0000000000000020                                
R10: 0000000000000000 R11: 000000000000006e R12: ffff88007e3a6800                                
R13: ffff880037659d18 R14: ffff88007e3a6800 R15: ffff880037659d18                                
FS:  00007f5b63f24790(0000) GS:ffff880001900000(0000) knlGS:0000000000000000                     
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033                                                
CR2: ffffffff00000080 CR3: 000000007e3b6000 CR4: 00000000000006e0                                
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000                                
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400                                
Process Xorg (pid: 1857, threadinfo ffff880037658000, task ffff8800376a86e0)                     
Stack:                                                                                           
 ffff88007c6d2ec0 0000000000000000 ffff88007c6d3158 ffffffff813513ab                             
<0> ffff88007f002dc0 ffff880000000040 fffffff57f35a800 ffff88007e025000                          
<0> 0000000000001000 ffff880037659d48 ffff88007e3a6800 ffff88007e026800                          
Call Trace:                                                                                      
 [<ffffffff813513ab>] ? unix_stream_recvmsg+0x28b/0x620
 [<ffffffff811e5976>] ? idr_get_new_above_int+0x16/0x90
 [<ffffffffa00961b0>] ? i915_gem_execbuffer+0x210/0x410 [i915]
 [<ffffffffa00904d5>] ? i915_gem_sw_finish_ioctl+0x95/0xd0 [i915]
 [<ffffffffa0040958>] ? drm_ioctl+0x308/0x440 [drm]
 [<ffffffffa0095fa0>] ? i915_gem_execbuffer+0x0/0x410 [i915]
 [<ffffffff8111ef2f>] ? do_sync_read+0xbf/0x100
 [<ffffffff81071924>] ? bit_waitqueue+0x14/0xc0
 [<ffffffff8112eed5>] ? vfs_ioctl+0x35/0xd0
 [<ffffffff8112f098>] ? do_vfs_ioctl+0x88/0x570
 [<ffffffff810566b3>] ? do_setitimer+0x1c3/0x240
 [<ffffffff8112f600>] ? sys_ioctl+0x80/0xa0
 [<ffffffff8100a002>] ? system_call_fastpath+0x16/0x1b
Code: eb 48 8b 74 24 68 44 8b 4e 08 45 85 c9 74 4a 4c 8b 64 24 50 31 ed 49 89 f5 0f 1f 00 48 63 c5 49 8d 04 c4 48 8b 10 48 85 d2 74 25 <48> 8b 92 80 00 00 00 c7 82 a0 00 00 00 00 00 00 00 48 8b 38 48
RIP  [<ffffffffa00951af>] i915_gem_do_execbuffer+0x79f/0x1370 [i915]
 RSP <ffff880037659bf8>
CR2: ffffffff00000080
---[ end trace 465d589b5d608009 ]---

Reverting 859ddf09743a8cc680af33f7259ccd0fd36bfe9d "idr: fix a critical 
misallocation bug" however fixes the problem on 2.6.33-rc6-git4 (and 
queue-2.6.32), KDE 4.3.4 starts up correctly and the oops is gone.

> 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...

Regards
	Stefan Lippers-Hollmann

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: patch idr-fix-a-critical-misallocation-bug.patch added to 2.6.32-stable tree
  2010-02-04 15:41         ` Stefan Lippers-Hollmann
@ 2010-02-11  8:51           ` Tejun Heo
  2010-02-11 14:32             ` Stefan Lippers-Hollmann
  0 siblings, 1 reply; 6+ messages in thread
From: Tejun Heo @ 2010-02-11  8:51 UTC (permalink / raw)
  To: Stefan Lippers-Hollmann
  Cc: Greg KH, linux-kernel, Eric Paris, akpm, torvalds, stable

Hello,

Can you please test the following patch on top of the current
mainline?

Thanks.

diff --git a/lib/idr.c b/lib/idr.c
index 1cac726..0dc7822 100644
--- a/lib/idr.c
+++ b/lib/idr.c
@@ -156,10 +156,12 @@ static int sub_alloc(struct idr *idp, int *starting_id, struct idr_layer **pa)
 			id = (id | ((1 << (IDR_BITS * l)) - 1)) + 1;
 
 			/* if already at the top layer, we need to grow */
-			if (!(p = pa[l])) {
+			if (id >= 1 << (idp->layers * IDR_BITS)) {
 				*starting_id = id;
 				return IDR_NEED_TO_GROW;
 			}
+			p = pa[l];
+			BUG_ON(!p);
 
 			/* If we need to go up one layer, continue the
 			 * loop; otherwise, restart from the top.

-- 
tejun

^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: patch idr-fix-a-critical-misallocation-bug.patch added to 2.6.32-stable tree
  2010-02-11  8:51           ` Tejun Heo
@ 2010-02-11 14:32             ` Stefan Lippers-Hollmann
  0 siblings, 0 replies; 6+ messages in thread
From: Stefan Lippers-Hollmann @ 2010-02-11 14:32 UTC (permalink / raw)
  To: Tejun Heo; +Cc: Greg KH, linux-kernel, Eric Paris, akpm, torvalds, stable

Hi

On Thursday 11 February 2010, Tejun Heo wrote:
> Hello,
> 
> Can you please test the following patch on top of the current
> mainline?
> 
> Thanks.

This works fine for me on 2.6.33-rc7-git5 plus your patch:

KMS enabled:
ii  xserver-xorg-video-intel 2:2.9.1-2          X.Org X server -- Intel i8xx, i9xx display driver
- 00:02.0 VGA compatible controller [0300]: Intel Corporation 82945G/GZ Integrated Graphics Controller [8086:2772] (rev 02)
  00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GME Express Integrated Graphics Controller [8086:27ae] (rev 03)

KMS enabled:
ii  xserver-xorg-video-radeon 1:6.12.4-3         X.Org X server -- ATI Radeon display driver
- 01:00.0 VGA compatible controller [0300]: ATI Technologies Inc RV630 [Radeon HD 2600 Series] [1002:9589]
  01:00.1 Audio device [0403]: ATI Technologies Inc RV630/M76 audio device [Radeon HD 2600 Series] [1002:aa08]
- 05:00.0 VGA compatible controller [0300]: ATI Technologies Inc RV370 5B60 [Radeon X300 (PCIE)] [1002:5b60]
  05:00.1 Display controller [0380]: ATI Technologies Inc RV370 [Radeon X300SE] [1002:5b70]
- 01:00.0 VGA compatible controller [0300]: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] [1002:4e50]
- 01:00.0 VGA compatible controller [0300]: ATI Technologies Inc RV280 [Radeon 9200 PRO] [1002:5960] (rev 01)
  01:00.1 Display controller [0380]: ATI Technologies Inc RV280 [Radeon 9200 PRO] (Secondary) [1002:5940] (rev 01)

no KMS available (Debian unstable has no matching xserver-xorg-video-nouveau
yet):
ii  xserver-xorg-video-nv 1:2.1.15-1         X.Org X server -- NV display driver
- 01:00.0 VGA compatible controller [0300]: nVidia Corporation NV11 [GeForce2 MX/MX 400] [10de:0110] (rev a1)

Tested-by: Stefan Lippers-Hollmann <s.l-h@gmx.de>

Thank you a lot
	Stefan Lippers-Hollmann

-- 
> diff --git a/lib/idr.c b/lib/idr.c
> index 1cac726..0dc7822 100644
> --- a/lib/idr.c
> +++ b/lib/idr.c
> @@ -156,10 +156,12 @@ static int sub_alloc(struct idr *idp, int *starting_id, struct idr_layer **pa)
>  			id = (id | ((1 << (IDR_BITS * l)) - 1)) + 1;
>  
>  			/* if already at the top layer, we need to grow */
> -			if (!(p = pa[l])) {
> +			if (id >= 1 << (idp->layers * IDR_BITS)) {
>  				*starting_id = id;
>  				return IDR_NEED_TO_GROW;
>  			}
> +			p = pa[l];
> +			BUG_ON(!p);
>  
>  			/* If we need to go up one layer, continue the
>  			 * loop; otherwise, restart from the top.

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2010-02-11 14:32 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <12651725962428@site>
     [not found] ` <1265203299.2919.1.camel@localhost>
     [not found]   ` <20100203233720.GA28271@suse.de>
2010-02-04  3:46     ` patch idr-fix-a-critical-misallocation-bug.patch added to 2.6.32-stable tree Stefan Lippers-Hollmann
2010-02-04  3:56       ` Tejun Heo
2010-02-04  8:36         ` Xiaotian Feng
2010-02-04 15:41         ` Stefan Lippers-Hollmann
2010-02-11  8:51           ` Tejun Heo
2010-02-11 14:32             ` Stefan Lippers-Hollmann

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox