From owner-freebsd-bugs@FreeBSD.ORG Tue Aug 26 09:30:17 2003 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0C55716A4BF for ; Tue, 26 Aug 2003 09:30:17 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id F345043FF5 for ; Tue, 26 Aug 2003 09:30:15 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h7QGUFUp024659 for ; Tue, 26 Aug 2003 09:30:15 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h7QGUFpQ024658; Tue, 26 Aug 2003 09:30:15 -0700 (PDT) Resent-Date: Tue, 26 Aug 2003 09:30:15 -0700 (PDT) Resent-Message-Id: <200308261630.h7QGUFpQ024658@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Jilles Tjoelker Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD6B316A4BF for ; Tue, 26 Aug 2003 09:27:17 -0700 (PDT) Received: from hexagon.stack.nl (hexagon.stack.nl [131.155.140.144]) by mx1.FreeBSD.org (Postfix) with ESMTP id 51C9E43FBD for ; Tue, 26 Aug 2003 09:27:16 -0700 (PDT) (envelope-from jilles@stack.nl) Received: from turtle.stack.nl (turtle.stack.nl [2001:610:1108:5010:2e0:81ff:fe22:51d8]) by hexagon.stack.nl (Postfix) with ESMTP id 549E31C3A for ; Tue, 26 Aug 2003 18:27:15 +0200 (CEST) Received: by turtle.stack.nl (Postfix, from userid 1677) id 44E761CC56; Tue, 26 Aug 2003 18:27:15 +0200 (CEST) Message-Id: <20030826162715.44E761CC56@turtle.stack.nl> Date: Tue, 26 Aug 2003 18:27:15 +0200 (CEST) From: Jilles Tjoelker To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Subject: kern/56008: ps shows L flag erroneously with certain selection options X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Jilles Tjoelker List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2003 16:30:17 -0000 >Number: 56008 >Category: kern >Synopsis: ps shows L flag erroneously with certain selection options >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Aug 26 09:30:15 PDT 2003 >Closed-Date: >Last-Modified: >Originator: Jilles Tjoelker >Release: FreeBSD 5.1-CURRENT i386 >Organization: MCGV Stack >Environment: System: FreeBSD turtle.stack.nl 5.1-CURRENT FreeBSD 5.1-CURRENT #12: Mon Aug 11 14:45:37 CEST 2003 root@turtle.stack.nl:/usr/obj/usr/src/sys/TURTLE i386 FreeBSD hexagon2.stack.nl 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Thu Aug 7 02:38:59 CEST 2003 dean@hexagon2.stack.nl:/usr/obj/turtle.mnt/usr.src/sys/HEXAGON2 sparc64 >Description: I'm seeing this on two 5-CURRENT machines, i386 and sparc64. On some processes, the 'L' status (not as first letter, so it means 'has pages locked in core', is shown or not depending on the selection options to ps (presumably, whether kern.proc.all, kern.proc.uid or ... is used). These systems were upgraded in the meantime, but the problem persists. >How-To-Repeat: Examine the same process repeatedly with different selection options. With selection by uid or terminal (and in a somewhat older version, all processes), ps erroneously shows that the process has pages locked in core ('L'). jilles@hexagon2 ~> ps axww | grep '^ 465' 465 a ILs+ 0:00.03 /usr/libexec/getty 3wire.9600 ttya jilles@hexagon2 ~> ps 465 PID TT STAT TIME COMMAND 465 a Is+ 0:00.03 /usr/libexec/getty 3wire.9600 ttya jilles@hexagon2 ~> ps axww | grep '^ 465' 465 a ILs+ 0:00.03 /usr/libexec/getty 3wire.9600 ttya jilles@hexagon2 ~> ps 465 PID TT STAT TIME COMMAND 465 a Is+ 0:00.03 /usr/libexec/getty 3wire.9600 ttya jilles@hexagon2 ~> ps ta PID TT STAT TIME COMMAND 465 a ILs+ 0:00.03 /usr/libexec/getty 3wire.9600 ttya jilles@hexagon2 ~> ps U root|grep '^ 465' 465 a ILs+ 0:00.03 /usr/libexec/getty 3wire.9600 ttya jilles@hexagon2 ~> jilles@turtle /home/jilles$ ps U jilles # uses kern.proc.uid PID TT STAT TIME COMMAND 3131 ?? RL 0:00.10 sshd: jilles@ttyp8 (sshd) 4307 ?? SL 0:00.02 sshd: jilles@ttyp9 (sshd) 3132 p8 SLs 0:00.09 -bash (bash) 4353 p8 RL+ 0:00.00 ps U jilles 4308 p9 SLs+ 0:00.04 -bash (bash) jilles@turtle /home/jilles$ ps U jilles,games # uses kern.proc.all PID TT STAT TIME COMMAND 3131 ?? R 0:00.10 sshd: jilles@ttyp8 (sshd) 4307 ?? S 0:00.02 sshd: jilles@ttyp9 (sshd) 3132 p8 Ss 0:00.09 -bash (bash) 4354 p8 R+ 0:00.00 ps U jilles,games 4308 p9 Ss+ 0:00.04 -bash (bash) jilles@turtle /home/jilles$ ps tp9 # uses kern.proc.tty PID TT STAT TIME COMMAND 4308 p9 ILs+ 0:00.04 -bash (bash) jilles@turtle /home/jilles$ ps 4308 # uses kern.proc.pid PID TT STAT TIME COMMAND 4308 p9 Is+ 0:00.04 -bash (bash) jilles@turtle /home/jilles$ >Fix: When using -U with multiple user names, ps requests all processes from the kernel and filters itself. When using -U with one name, ps requests the kernel for processes of that user only. The cause seems to be this commit to src/sys/kern/kern_proc.c: > Revision 1.188 / (download) - annotate - [select for diffs], Thu Jun 12 > 16:41:50 2003 UTC (2 months, 1 week ago) by scottl > Branch: MAIN > Changes since 1.187: +89 -55 lines > Diff to previous 1.187 (colored) > > Add support to sysctl_kern_proc to return all threads in a proc, not > just the first one. The old behaviour can be switched by specifying > KERN_PROC_PROC. > > Submitted by: julian, tweaks and added functionality by myself When iterating over the threads in a process, it does _PHOLD(p), which increments p->p_lock and causes ps to show 'L' state flag (kp->ki_lock). If KERN_PROC_NOTHREADS is used, FIRST_THREAD_IN_PROC(p) is used without _PHOLD(p), so p->p_lock is returned as it should be. A simple way to fix this would be adding an argument to fill_kinfo_thread() that it must subtract one from p->p_lock, but this may not be the correct solution. Is _PHOLD required for FOREACH_THREAD_IN_PROC? Is it required for FIRST_THREAD_IN_PROC? Also, could this _PHOLD result in data being paged in for ps? >Release-Note: >Audit-Trail: >Unformatted: