Messages in this thread | | | Date | Fri, 11 Dec 2015 12:04:15 -0700 | Subject | Re: [PATCH v2 1/1] Fix int1 recursion when no perf_bp_event is registeredy | From | Jeff Merkey <> |
| |
One thing I noticed in this section of code:
/* Handle all the breakpoints that were triggered */ for (i = 0; i < HBP_NUM; ++i) { if (likely(!(dr6 & (DR_TRAP0 << i)))) continue;
... snip ...
if (bp->hw.info.type == X86_BREAKPOINT_EXECUTE) args->regs->flags |= X86_EFLAGS_RF;
rcu_read_unlock(); }
Whoever wrote this loop did not seem to understand have observed the code path in action on intel hardware. There is NEVER a case I have seen when the hardware sends multiple breakpoint statuses through dr6, they are sent one at a time. So the rolling check through all the status bits is pointless since only one breakpoint will be reported by the hardware at a time. This is not to say that someone in the future might may change it, but these interrupts are delivered one by one in order and if there are duplicates (like a read/write breakpoint set at the same address as an execute breakpoint.
Does anyone know why it was coded this way because its flat wrong.
Jeff
| |