| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-Id: <1247775887.10888.17.camel@wall-e> Date: Thu, 16 Jul 2009 22:24:47 +0200 From: Stefani Seibold <stefani@...bold.net> To: Valdis.Kletnieks@...edu Cc: Andrew Morton <akpm@...ux-foundation.org>, linux-kernel@...r.kernel.org Subject: Re: 2.6.31-rc1-mmotm0702 - ps command hangs inside kernel On Thu, 16 Jul 2009, 15:12 -0400 Valdis.Kletnieks@...edu said: > On Tue, 14 Jul 2009 07:31:19 +0200, Stefani Seibold said: > > Am Montag, den 13.07.2009, 14:38 -0700 schrieb Andrew Morton: > > > On Mon, 13 Jul 2009 16:54:51 -0400 > > > Valdis.Kletnieks@...edu wrote: > > > > > > > Several times recently, I've had the 'ps' command hang inside the kernel > > > > for extended periods of time - usually around 1100 seconds, but today I > > > > had one that hung there for 2351 seconds. > > > i am the author of the get_stack_usage_bytes(). Because i have currently > > no 64bit machine running, i am not able to analyse your problem. Does it > > only happen on 32bit application on a 64bit kernel? Is it only affected > > to pcsd? > > I've only seen it happen to pcscd. However, most of the time it's one of > the very few 32-bit apps running on my laptop (I've got exactly *one* legacy > app for a secure-token that is stuck in 32-bit land). So I can't tell if it's > a generic 32-bit issue. > > It's possible that one of the two follow_page() entries is stale and just > happened to be left on the stack. A large chunk of proc_pid_status() is > inlined, so it's possible that two calls were made and left their return > addresses in different locations on the stack. > > I am pretty sure that follow_page+0x28 is the correct one, as I see it > in 2 more tracebacks today (see below)... The stack trace looks like you there is a old version included in the 2.6.31-rc1-mmotm0702 patches. I switch to walk_page_range() function since patch version V0.9 dated from Jun 10 2009. Here is the link to the lkml patchwork: http://patchwork.kernel.org/patch/32210/ I do the map examination exactly in the same way like the function used for /proc/<pid>/smaps. So i think this version should do it without side effects. Can you tell me were you downloaded the 2.6.31-rc1-mmotm0702 patch? > ps R running task 3936 45836 45832 0x00000080 > ffff88004dc09b98 ffffffff81065f3f 0000000000000001 00000388525af000 > ffff88004dc09bb8 ffffffff81065f3f 0000000000000000 000003886bc2b000 > ffff88004dc09ce8 ffffffff8149b2a6 0000000000000000 ffff88000212cf68 > Call Trace: > [<ffffffff81065f3f>] ? trace_hardirqs_on_caller+0x1f/0x145 > [<ffffffff81065f3f>] trace_hardirqs_on_caller+0x1f/0x145 > [<ffffffff8149b2a6>] trace_hardirqs_on_thunk+0x3a/0x3f > [<ffffffff81065f3f>] ? trace_hardirqs_on_caller+0x1f/0x145 > [<ffffffff8149b2a6>] ? trace_hardirqs_on_thunk+0x3a/0x3f > [<ffffffff8101f76b>] ? smp_apic_timer_interrupt+0x81/0x8f > [<ffffffff810b8222>] ? IS_ERR+0x25/0x2c > [<ffffffff810b8f22>] ? follow_page+0x28/0x2e3 > [<ffffffff811219d8>] proc_pid_status+0x5e0/0x694 > [<ffffffff81066072>] ? trace_hardirqs_on+0xd/0xf > [<ffffffff8111e42c>] proc_single_show+0x57/0x74 > [<ffffffff810e90b4>] seq_read+0x249/0x49b > [<ffffffff8116c840>] ? security_file_permission+0x11/0x13 > [<ffffffff810d05e1>] vfs_read+0xe0/0x141 > [<ffffffff810d8191>] ? path_put+0x1d/0x21 > [<ffffffff810d06f8>] sys_read+0x45/0x69 > [<ffffffff8100b2ab>] system_call_fastpath+0x16/0x1b -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists