ps pages locked in core weirdness

[Jilles Tjoelker]

Hello,

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
and I have found it in the source code.

jilles at hexagon2 ~> ps axww | grep '^  465'
  465   a  ILs+   0:00.03 /usr/libexec/getty 3wire.9600 ttya
jilles at hexagon2 ~> ps 465
  PID  TT  STAT      TIME COMMAND
  465   a  Is+    0:00.03 /usr/libexec/getty 3wire.9600 ttya
jilles at hexagon2 ~> ps axww | grep '^  465'
  465   a  ILs+   0:00.03 /usr/libexec/getty 3wire.9600 ttya
jilles at hexagon2 ~> ps 465
  PID  TT  STAT      TIME COMMAND
  465   a  Is+    0:00.03 /usr/libexec/getty 3wire.9600 ttya
jilles at hexagon2 ~> ps ta
  PID  TT  STAT      TIME COMMAND
  465   a  ILs+   0:00.03 /usr/libexec/getty 3wire.9600 ttya
jilles at hexagon2 ~> ps U root|grep '^  465'
  465   a  ILs+   0:00.03 /usr/libexec/getty 3wire.9600 ttya
jilles at hexagon2 ~> uname -a
FreeBSD hexagon2.stack.nl 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Thu Aug  7
02:38:59 CEST 2003
dean at hexagon2.stack.nl:/usr/obj/turtle.mnt/usr.src/sys/HEXAGON2  sparc64
jilles at hexagon2 ~> 

jilles at turtle /home/jilles$ ps U jilles # uses kern.proc.uid
  PID  TT  STAT      TIME COMMAND
 3131  ??  RL     0:00.10 sshd: jilles at ttyp8 (sshd)
 4307  ??  SL     0:00.02 sshd: jilles at 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 at turtle /home/jilles$ ps U jilles,games # uses kern.proc.all
  PID  TT  STAT      TIME COMMAND
 3131  ??  R      0:00.10 sshd: jilles at ttyp8 (sshd)
 4307  ??  S      0:00.02 sshd: jilles at 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 at turtle /home/jilles$ ps tp9 # uses kern.proc.tty
  PID  TT  STAT      TIME COMMAND
 4308  p9  ILs+   0:00.04 -bash (bash)
jilles at turtle /home/jilles$ ps 4308 # uses kern.proc.pid
  PID  TT  STAT      TIME COMMAND
 4308  p9  Is+    0:00.04 -bash (bash)
jilles at turtle /home/jilles$ uname -a
FreeBSD turtle.stack.nl 5.1-CURRENT FreeBSD 5.1-CURRENT #11: Mon Jul 28
15:11:04 CEST 2003     jwk at turtle.stack.nl:/usr/obj/usr/src/sys/TURTLE
i386
jilles at turtle /home/jilles$ 

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?

Jilles Tjoelker