[Crash-utility] ps: issue with "waking" and "parked" task states?

[Dave Anderson]

Hi Michael,

I have to thank you again for the report.  As it turns out, the task state
gathering and display functionality needed several updates and fixes that 
are queued for crash-7.1.2: 

  https://github.com/crash-utility/crash/commit/cd93c8a0b50008690e4c116ddb9215b1ea0f36d1

  Several fixes associated with the gathering and display of task
  state.  Without the patch:
    (1) The "ps" command's ST column shows "??" for tasks in the
        TASK_WAKING state.
    (2) The "ps" command's ST column shows "??" for tasks in the
        TASK_PARKED state in Linux 3.14 and later kernels.
    (3) The STATE field of the initial system banner and the "set"
        command are incorrect if the task state has the TASK_WAKING,
        TASK_WAKEKILL modifier, or TASK_PARKED bits set in Linux 3.14
        and later kernels.
    (4) The "foreach DE" task identifier fails if a task with a PID
        number of 0xDE (222) exists.
    (5) The "foreach" command's "SW", "PA", "TR" and "DE" task
        identifiers inadvertently select all tasks in kernel versions
        that do not have those states.
    (6) The "help -t" output would display incorrect values for the
        TASK_WAKEKILL, TASK_WAKING and TASK_PARKED states in Linux 3.14
        and later kernels.
  Lastly, support for the TASK_NOLOAD modifier introduced in Linux 4.2
  has been added to STATE field of the "set" command and the initial
  system banner.
  (anderson at redhat.com)

Dave

  

----- Original Message -----
> 
> 
> ----- Original Message -----
> > 
> > 
> > ----- Original Message -----
> > > Hi Dave,
> > > 
> > > I recently looked into a linux 4.0 dump where the "ps" command prints
> > > "??"
> > > for the state field of several tasks:
> > > 
> > > crash> ps
> > >     741    660   1      7b408000      ??   0.0    2152   2592  chcpu
> > >     748      2  24      20c284f00     IN   0.0       0      0
> > >     [migration/24]
> > >     752      2  22      20b1ccf00     ??   0.0       0      0
> > >     [migration/25]
> > > 
> > > Looking at the "task_struct->state" I get the following:
> > > 
> > >  crash> task_struct 7b408000 | grep state
> > >    state = 0x100,
> > >  crash> task_struct 20b1ccf00 | grep state
> > >    state = 0x200
> > > 
> > > Looking into include/linux/sched.h states are defined as follows:
> > > 
> > >  #define TASK_RUNNING            0
> > >  ...
> > >  #define TASK_WAKING             256
> > >  #define TASK_PARKED             512
> > > 
> > > When I issue "help -t" I get the following:
> > > 
> > >            RUNNING:   0 (0x0)
> > >      INTERRUPTIBLE:   1 (0x1)
> > >    UNINTERRUPTIBLE:   2 (0x2)
> > >            STOPPED:   4 (0x4)
> > >    TRACING_STOPPED:   8 (0x8)
> > >             ZOMBIE:  32 (0x20)
> > >               DEAD:  16 and 32 (0x10 and 0x20)
> > >           WAKEKILL:  64 (0x40)
> > >             WAKING: 128 (0x80)  <- Should be 256?
> > > 
> > > I have not digged deeper, but at least wanted to report this issue.
> > > Perhaps you see the problem at once.
> > > 
> > > Michael
> > > 
> > > 
> > 
> > I see it now.  The states are gathered from the kernel's
> > task_state_array[].
> > So on a 3.9-based kernel, for example, it's this:
> > 
> > crash> p task_state_array
> > task_state_array = $1 =
> >  {0xffffffff81a01959 "R (running)", 0xffffffff81a01965 "S (sleeping)",
> >  0xffffffff81a01972 "D (disk sleep)", 0xffffffff81a01981 "T (stopped)",
> >  0xffffffff81a0198d "t (tracing stop)", 0xffffffff81a0199e "Z (zombie)",
> >  0xffffffff81a019a9 "X (dead)", 0xffffffff81a019b2 "x (dead)",
> >  0xffffffff81a019bb "K (wakekill)", 0xffffffff81a019c8 "W (waking)",
> >  0xffffffff81a019d3 "P (parked)"}
> > crash>
> > 
> > And for example, here's the 3.10 kernel's declaration:
> > 
> > /*
> >  * The task state array is a strange "bitmap" of
> >  * reasons to sleep. Thus "running" is zero, and
> >  * you can test for combinations of others with
> >  * simple bit tests.
> >  */
> > static const char * const task_state_array[] = {
> >         "R (running)",          /*   0 */
> >         "S (sleeping)",         /*   1 */
> >         "D (disk sleep)",       /*   2 */
> >         "T (stopped)",          /*   4 */
> >         "t (tracing stop)",     /*   8 */
> >         "Z (zombie)",           /*  16 */
> >         "X (dead)",             /*  32 */
> >         "x (dead)",             /*  64 */
> >         "K (wakekill)",         /* 128 */
> >         "W (waking)",           /* 256 */
> >         "P (parked)",           /* 512 */
> > };
> > 
> > where on a 4.0.5 kernel, the wakekill, waking and parked fields no longer
> > exist in the array:
> > 
> > crash> p task_state_array
> > task_state_array = $1 =
> >  {0xffffffff81a73b42 "R (running)", 0xffffffff81a73b4e "S (sleeping)",
> >  0xffffffff81a73b5b "D (disk sleep)", 0xffffffff81a73b6a "T (stopped)",
> >  0xffffffff81a73b76 "t (tracing stop)", 0xffffffff81a73b87 "X (dead)",
> >  0xffffffff81a73b90 "Z (zombie)"}
> > crash>
> > 
> > This is the upstream kernel declaration:
> > 
> > static const char * const task_state_array[] = {
> >         "R (running)",          /*   0 */
> >         "S (sleeping)",         /*   1 */
> >         "D (disk sleep)",       /*   2 */
> 
> >         "T (stopped)",          /*   4 */
> >         "t (tracing stop)",     /*   8 */
> >         "X (dead)",             /*  16 */
> >         "Z (zombie)",           /*  32 */
> > };
> > 
> > Not sure where the wakekill, waking, and parked went yet though...
> > 
> > Dave
> 
> Looks like I should probably change the scheme to gather the state
> information
> from the stat_nam[] string instead:
> 
>   #define TASK_STATE_TO_CHAR_STR "RSDTtXZxKWP"
> 
>   static const char stat_nam[] = TASK_STATE_TO_CHAR_STR;
> 
> Thanks for the heads-up.
>   Dave
> 
>