Page MenuHomeFreeBSD

Only clear a pending thread event if one is pending.
ClosedPublic

Authored by jhb on Oct 30 2017, 5:24 PM.
Tags
None
Referenced Files
F109246226: D12837.diff
Sun, Feb 2, 1:50 PM
Unknown Object (File)
Dec 23 2024, 12:12 AM
Unknown Object (File)
Nov 28 2024, 8:35 AM
Unknown Object (File)
Oct 20 2024, 9:07 PM
Unknown Object (File)
Oct 19 2024, 10:59 PM
Unknown Object (File)
Oct 1 2024, 3:51 PM
Unknown Object (File)
Sep 28 2024, 2:13 AM
Unknown Object (File)
Sep 23 2024, 12:04 PM
Subscribers

Details

Summary

If only P_STOPPED_SIG is set but not P_STOPPED_TRACE, then p_xthread
might be NULL. While here, try to adjust some comments to more
clearly document some of the cases.

There are some XXX questions I've added that I'd like some feedback on.
I can either adjust code and/or comments based on feedback. I haven't
run Peter's stress test against this but simple tests in kyua pass.

Test Plan
  • tests/sys/kern/ptrace_test

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 12309
Build 12598: arc lint + arc unit

Event Timeline

I ran all of the ptrace(2) scenarios several times, without seeing any problems.

sys/kern/sys_process.c
1132

Should this comment become an assertion ?

1159

I prefer to move the previous P_STOPPED_TRACE block above the beginning of the P_STOPPED_SIG|P_STOPPED_TRACE block and then move the p_xsig = data into it.
At least it reduces the indent.

1179

Commit this comment enhancement separately, perhaps ?

1195

I am not sure that I understand this comment fully. Do you mean that the assert there should be

MPASS(td2 != NULL || req == PT_ATTACH);
1205

What condition do you mean to be always true ? The data != 0 ? What if userspace does ptrace(PT_CONTINUE, data = 0) ?

jhb marked an inline comment as done.Nov 13 2017, 6:25 PM
jhb added inline comments.
sys/kern/sys_process.c
871

I think this can change to require P_STOPPED_TRACE. In kern_sig.c we never set P_STOPPED_SIG without P_STOPPED_TRACE on a traced process.

1132

I don't think it is required for correctness. At one point I had looked at "inlining" the sendsig handling for PT_ATTACH and PT_KILL to avoid the goto and see if the resulting code was simpler, but it wasn't. I do want to document a bit which parts are different though for the different cases.

1195

No, I would need some new variable to hold the "old" value of p_xthread before it was cleared. However, all of the requests that get to this point require P_STOPPED_TRACE other than PT_ATTACH.

1205

Any request other than PT_ATTACH fails if P_STOPPED_TRACE isn't set (see my note up above on line 871), so we can only be in this case for PT_ATTACH I believe.

  • Move P_STOPPED_TRACE section up.
  • Require P_STOPPED_TRACE for most actions.
  • Clarify some comments.
  • Consolidate kern_psignal cases for PT_ATTACH.

I will probably try to "uninline" the PT_ATTACH case as a followup after this. After the last bits of refactoring I think it will probably be worth it.

kib added inline comments.
sys/kern/sys_process.c
878

Is this something local ?

This revision is now accepted and ready to land.Nov 13 2017, 7:39 PM
sys/kern/sys_process.c
878

Nope, added in rS153697

This revision was automatically updated to reflect the committed changes.