Move KTRUSERRET() from userret() to ast(). It's a really long
detour - it writes ktrace entries to the filesystem - so the
overhead of ast() won't make any difference.
Details
Details
- Reviewers
kib - Commits
- rS366391: Move KTRUSERRET() from userret() to ast(). It's a really long
Diff Detail
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 33505 Build 30776: arc lint + arc unit
Event Timeline
Comment Actions
Please flush existing accepted reviews before adding more things touching the same place.
| sys/kern/subr_trap.c | ||
|---|---|---|
| 282 | Idea is that we do not return to userspace with ktrace records not flushed. But look at the lines 280-283. It generates new ktrace record. At best, this would set ASTPENDING again. | |
| 327 | This function accesses userspace pages and might generate KTR. | |
| 336 | This function also generates ktrsig records. | |
| sys/kern/subr_trap.c | ||
|---|---|---|
| 282 | Good point. I'm kind of split about this. On one hand your you're of course right, we should flush the records before returning. On the other hand, the current code didn't do that. On yet another... limb, the current code didn't trigger AST. Perhaps it could be split into two patches, first moving this in a minimally intrusive way (ie the current patch), and subsequent patch moving it more to the end of ast()? I'm exactly 50/50 about this, so if you prefer it to move the call to KTRUSERRET() more to the end of ast(), I'll happily do that. | |
Comment Actions
I am sure that if you move ktrace records processing to AST, then the same change should ensure that we do not create new unprocessed (not written while in the handler) records while handling AST. Simplest form is to move the ktruserret to the end. More involved change would call ktruserret both at the start of AST and at the end as well. First call clears as much as possible immediately to lower mem pressure, and the call at end clears everything that was generated by AST processing.