Hi folks,
If nobody objects, I'd like to add the two attached patches to the into
our 2.4 tree.
Reason for (1): currently, ptrace(SINGLESTEP) [used by GDB] sets the UBC
registers, and break_point_trap() clears them. But the ASID put into the
UBC can be invalid if ASID rollover happens between the two schedulings of
the target process; then the SIGTRAP goes to the wrong task. Probably
unusual in normal operation, but I still think it's A Bad Thing. Or, if
there are multiple GDBs or GDB threads such that a second ptrace() call is
made before the first target task resumes, the UBC will be overwritten and
the first trap will never happen.
Anyway, this patch attempts to address the problem by having ptrace() set
the UBC values in the thread_struct of the task; only in __switch_to(),
when the task is scheduled [and any new ASID already assigned] will the
settings be put in the UBC registers; switching to a task w/o UBC settings
in its thread_struct makes sure the UBC registers are cleared. The
thread_struct fields are cleared when the trap is hit or the thread exits.
Trying to minimize the runtime code path in __switch_to(), there's also a
global counter incremented by ptrace() and decremented by the trap handler
and exit_thread(); only when this is nonzero -- i.e. when some task is
using the UBC -- are the other checks made. Maybe this is overkill? [My
only concern with that was where to put the exit_thread() stuff; hope
that's the right place. Or is release_thread() better?]
Reason for (2): as it stands, flush_icache_range() clears the entire cache
(both I and D). I know a lot of work went into dealing with the cache
functions so I'm assuming that's the fastest way to do it -- but the
__flush_dcache_all() function that's used flushes everything _except_ the
first several K of kernel text memory. I guess this isn't a problem since
that wouldn't be in the D-cache (modified!) normally, but it torpedos KGDB
breakpoints there. This patch makes kgdb use __flush_purge_region() to
force the write-back.
Any complaints or suggestions?
Thanks,
--Jeremy Siegel
|
