KDL when checkout out stress-ng on 32bit

[Begasus]

Running stress-ng --cpu 4 --vm 2 --hdd 1 --fork 8 --timeout 2m --metrics in Terminal sends me into KDL

[waddlesplash]

Reproducible?

[Begasus]

Yes, tried with stress-ng --cpu 2 --vm 2 --hdd 1 --fork 8 --timeout 2m --metrics as I only have 2 cpu's here, still send me into KDL

[waddlesplash]

This is reproducible on x86_64, though it seems a bit intermittently.

[waddlesplash]

Dumping a team structure in the KDL:

TEAM: 0xffffffff86d36408
id:               637 (0x27d)
serial_number:    252
name:             'stress-ng'
args:             '/bin/stress-ng --cpu 4 --vm 2 --hdd 1 --fork 8 --timeout 2m --m'
hash_next:        0x0000000000000000
parent:           0xffffffff86d3f008 (id = 624)
children:         0x0000000000000000
num_threads:      1
state:            1
flags:            0x0
io_context:       0xffffffff86ee4c00
address_space:    0xffffffff86ac4ca0
user data:        0x00007f613b102000 (area 15547)
free user thread: 0x0000000000000000
main_thread:      0xffffffff86fdcfc0
thread_list:      0xffffffff86fdcfc0
group_id:         624
session_id:       411

Note that state=1, i.e. TEAM_STATE_BIRTH. That's a little unexpected, shouldn't it be TEAM_STATE_NORMAL at the point we enter userland?

[waddlesplash]

The problem is that the process has no group, i.e. in LockTeamAndProcessGroup. Is that a legal state for a team to have? Because quite a lot of this code does not handle that case...

[waddlesplash]

After making some other tweaks, it seems group_id is always non-zero while group is still NULL. So that indicates something else is going wrong, indeed.

The state being 1 is an oversight in fork_team and isn't related.

[waddlesplash]

Ah, I think this occurs in the middle of the team destruction; the team structures above aren't the one actually being modified, and the one that is seems to be gone from the teams hash at the point we reach LockTeamAndProcessGroup.

[waddlesplash]

Fixed in hrev55886.