[<prev] [next>] [day] [month] [year] [list]
Message-ID: <1276680755.26231.16.camel@e102144-lin.cambridge.arm.com>
Date: Wed, 16 Jun 2010 10:32:35 +0100
From: Will Deacon <will.deacon@....com>
To: fweisbec@...il.com
Cc: linux-kernel@...r.kernel.org
Subject: Enabling a disabled hw-breakpoint using modify_user_hw_breakpoint
Hi Frederic,
In the ARM hw-breakpoint implementation, the ptrace API may create a new
breakpoint with attr->disabled = 1. At a later time, this may be updated
to 0 and modify_user_hw_breakpoint will be called to propagate the
changes.
As part of this callchain, the architecture-specific function
arch_validate_hwbkpt_settings is called with the breakpoint as a
parameter. The attr->disabled field is checked and the corresponding
`enabled' field in the ARM control register struct is set accordingly.
When arch_install_hw_breakpoint is called later on, the actual control
register is programmed with the values set in the struct. The problem is
that modify_user_hw_breakpoint doesn't update the bp->attr.disabled
field before calling the validate function:
if (attr->disabled)
goto end;
/* bp->attr.disabled still has the old value */
err = validate_hw_breakpoint(bp);
if (!err)
perf_event_enable(bp);
if (err) {
bp->attr.bp_addr = old_addr;
bp->attr.bp_type = old_type;
bp->attr.bp_len = old_len;
if (!bp->attr.disabled)
perf_event_enable(bp);
return err;
}
end:
bp->attr.disabled = attr->disabled;
For the time being, I always write the control register enable bit in
arch_install_hw_breakpoint (because this function shouldn't be called if
the breakpoint is disabled). Is this a sensible workaround, or does the
generic code need changing?
Thanks,
Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists