From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Rafael J. Wysocki" Subject: Re: [Bug #20472] [2.6.35.5 -> .7] INFO: task rpcbind:14163 blocked for more than 120 seconds. Date: Tue, 19 Oct 2010 22:30:22 +0200 Message-ID: <201010192230.22623.rjw@sisk.pl> References: <201010182336.51265.rjw@sisk.pl> <201010191804.00147.pluto@agmk.net> Mime-Version: 1.0 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <201010191804.00147.pluto-PIIpFW8S9c0@public.gmane.org> Sender: kernel-testers-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: Text/Plain; charset="utf-8" To: =?utf-8?q?Pawe=C5=82_Sikora?= Cc: Linux Kernel Mailing List , Kernel Testers List , Maciej Rutecki , Florian Mickler , Trond Myklebust , Arkadiusz Miskiewicz On Tuesday, October 19, 2010, Pawe=C5=82 Sikora wrote: > On Monday 18 October 2010 23:36:51 Rafael J. Wysocki wrote: > > On Monday, October 18, 2010, Pawe=C5=82 Sikora wrote: > > > On Sunday 17 October 2010 22:21:48 Rafael J. Wysocki wrote: > > > > This message has been generated automatically as a part of a su= mmary report > > > > of recent regressions. > > > >=20 > > > > The following bug entry is on the current list of known regress= ions > > > > from 2.6.35. Please verify if it still should be listed and le= t the tracking team > > > > know (either way). > > >=20 > > > hi, > > >=20 > > > hot news from the front, recent tests on the pld-linux.org vendor= kernel > > > show that the random task blocking in 2.6.35.7 during medium/heav= y load (~4..25) > > > is related to the grsecurity patch. we'll forward problem report = to the > > > grsec maintainer asap... > >=20 > > So, to make things clear, this is not a mainline kernel issue, is i= t? >=20 > i thought that was a grsecurity issue but now i have a testcase that > casues task blocking on my machine with the vanilla 2.6.35.7 kernel: >=20 > steps to repoduce: >=20 > on console 1: > - run 'make -j32' in kernel tree and wait several second for make for= ks > and medium system load (~15). >=20 > on console 2: > - run 'sync' from root account to bump load more. >=20 > on console 3: > - observe 'tail -f /var/log/kernel' for blocking issues. >=20 > [ 360.517917] INFO: task sync:6712 blocked for more than 120 seconds= =2E > [ 360.517920] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" dis= ables this message. > [ 360.517922] sync D 00000000ffff4c7c 0 6712 2770 0x= 00000000 > [ 360.517926] ffff88021ac71d18 0000000000000086 ffff880200000000 00= 00000000004000 > [ 360.517930] 0000000000013700 0000000000013700 ffff88021ac71fd8 ff= ff88021ac71fd8 > [ 360.517933] ffff880205593020 0000000000013700 ffff88021ac71fd8 00= 00000000004000 > [ 360.517936] Call Trace: > [ 360.517944] [] schedule_timeout+0x20d/0x2f0 > [ 360.517949] [] ? enqueue_entity+0xea/0x170 > [ 360.517951] [] ? enqueue_task_fair+0x49/0x50 > [ 360.517954] [] wait_for_common+0xc5/0x150 > [ 360.517957] [] ? default_wake_function+0x0/0x10 > [ 360.517959] [] wait_for_completion+0x18/0x20 > [ 360.517963] [] sync_inodes_sb+0x83/0x170 > [ 360.517967] [] ? sync_one_sb+0x0/0x20 > [ 360.517969] [] __sync_filesystem+0x80/0x90 > [ 360.517972] [] sync_one_sb+0x1b/0x20 > [ 360.517975] [] iterate_supers+0x77/0xc0 > [ 360.517978] [] sync_filesystems+0x1b/0x20 > [ 360.517980] [] sys_sync+0x1c/0x40 > [ 360.517984] [] system_call_fastpath+0x16/0x1b >=20 > the 'make' is running on ext4 filesystem with underlying mdadm (raid1= 0) > created from 2 caviar raid edition disks. the cpu is intel quad core > Q9300 with 8GB of ddr2 ram. So, how is this related to the original report? Rafael From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757273Ab0JSUbM (ORCPT ); Tue, 19 Oct 2010 16:31:12 -0400 Received: from ogre.sisk.pl ([217.79.144.158]:34285 "EHLO ogre.sisk.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753611Ab0JSUbK convert rfc822-to-8bit (ORCPT ); Tue, 19 Oct 2010 16:31:10 -0400 From: "Rafael J. Wysocki" To: =?utf-8?q?Pawe=C5=82_Sikora?= Subject: Re: [Bug #20472] [2.6.35.5 -> .7] INFO: task rpcbind:14163 blocked for more than 120 seconds. Date: Tue, 19 Oct 2010 22:30:22 +0200 User-Agent: KMail/1.13.5 (Linux/2.6.36-rc8-rjw+; KDE/4.4.4; x86_64; ; ) Cc: Linux Kernel Mailing List , Kernel Testers List , Maciej Rutecki , Florian Mickler , Trond Myklebust , Arkadiusz Miskiewicz References: <201010182336.51265.rjw@sisk.pl> <201010191804.00147.pluto@agmk.net> In-Reply-To: <201010191804.00147.pluto@agmk.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 8BIT Message-Id: <201010192230.22623.rjw@sisk.pl> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday, October 19, 2010, Paweł Sikora wrote: > On Monday 18 October 2010 23:36:51 Rafael J. Wysocki wrote: > > On Monday, October 18, 2010, Paweł Sikora wrote: > > > On Sunday 17 October 2010 22:21:48 Rafael J. Wysocki wrote: > > > > This message has been generated automatically as a part of a summary report > > > > of recent regressions. > > > > > > > > The following bug entry is on the current list of known regressions > > > > from 2.6.35. Please verify if it still should be listed and let the tracking team > > > > know (either way). > > > > > > hi, > > > > > > hot news from the front, recent tests on the pld-linux.org vendor kernel > > > show that the random task blocking in 2.6.35.7 during medium/heavy load (~4..25) > > > is related to the grsecurity patch. we'll forward problem report to the > > > grsec maintainer asap... > > > > So, to make things clear, this is not a mainline kernel issue, is it? > > i thought that was a grsecurity issue but now i have a testcase that > casues task blocking on my machine with the vanilla 2.6.35.7 kernel: > > steps to repoduce: > > on console 1: > - run 'make -j32' in kernel tree and wait several second for make forks > and medium system load (~15). > > on console 2: > - run 'sync' from root account to bump load more. > > on console 3: > - observe 'tail -f /var/log/kernel' for blocking issues. > > [ 360.517917] INFO: task sync:6712 blocked for more than 120 seconds. > [ 360.517920] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > [ 360.517922] sync D 00000000ffff4c7c 0 6712 2770 0x00000000 > [ 360.517926] ffff88021ac71d18 0000000000000086 ffff880200000000 0000000000004000 > [ 360.517930] 0000000000013700 0000000000013700 ffff88021ac71fd8 ffff88021ac71fd8 > [ 360.517933] ffff880205593020 0000000000013700 ffff88021ac71fd8 0000000000004000 > [ 360.517936] Call Trace: > [ 360.517944] [] schedule_timeout+0x20d/0x2f0 > [ 360.517949] [] ? enqueue_entity+0xea/0x170 > [ 360.517951] [] ? enqueue_task_fair+0x49/0x50 > [ 360.517954] [] wait_for_common+0xc5/0x150 > [ 360.517957] [] ? default_wake_function+0x0/0x10 > [ 360.517959] [] wait_for_completion+0x18/0x20 > [ 360.517963] [] sync_inodes_sb+0x83/0x170 > [ 360.517967] [] ? sync_one_sb+0x0/0x20 > [ 360.517969] [] __sync_filesystem+0x80/0x90 > [ 360.517972] [] sync_one_sb+0x1b/0x20 > [ 360.517975] [] iterate_supers+0x77/0xc0 > [ 360.517978] [] sync_filesystems+0x1b/0x20 > [ 360.517980] [] sys_sync+0x1c/0x40 > [ 360.517984] [] system_call_fastpath+0x16/0x1b > > the 'make' is running on ext4 filesystem with underlying mdadm (raid10) > created from 2 caviar raid edition disks. the cpu is intel quad core > Q9300 with 8GB of ddr2 ram. So, how is this related to the original report? Rafael