linux-kernel - Re: 2.6.31-rc1-mmotm0702 - ps command hangs inside kernel

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20090716134401.0b1bec77.akpm@linux-foundation.org>
Date:	Thu, 16 Jul 2009 13:44:01 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Stefani Seibold <stefani@...bold.net>
Cc:	Valdis.Kletnieks@...edu, linux-kernel@...r.kernel.org
Subject: Re: 2.6.31-rc1-mmotm0702 - ps command hangs inside kernel

On Thu, 16 Jul 2009 22:24:47 +0200
Stefani Seibold <stefani@...bold.net> wrote:

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

It would have been version 08.  I've now updated to v11.
--
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/