Hi,
The first two patches probably ought to go in x86/urgent, the rest (!RFC) can
go into x86/core and wait a bit.
handle_debug() is a mess, and now that we have separate user and kernel paths,
try and clean it up a bit.
There's two RFC patches at the end that impact the ptrace_{get,set}_debugreg(6)
ABI, I've no idea what, if anything, is expected of that or if anybody actually
cares about that. If I read the code correctly nothing actually consumes the
value from ptrace_set_debugreg(6).
Kyle, you seem to be pushing all this to the edge with RR, any clues?
Since v2:
- fixed (user) INT1 / icebp detection
- some further cleanups
- two additional RFC patches
On Wed, Sep 02, 2020 at 03:25:49PM +0200, Peter Zijlstra wrote:
> Hi,
>
> The first two patches probably ought to go in x86/urgent, the rest (!RFC) can
> go into x86/core and wait a bit.
>
> handle_debug() is a mess, and now that we have separate user and kernel paths,
> try and clean it up a bit.
>
> There's two RFC patches at the end that impact the ptrace_{get,set}_debugreg(6)
> ABI, I've no idea what, if anything, is expected of that or if anybody actually
> cares about that. If I read the code correctly nothing actually consumes the
> value from ptrace_set_debugreg(6).
I applied this both with and without the RFC patches and pointed the
(still work-in-progress) kgdb test suite at it. I won't pretend the
suite is comprehensive but nevertheless FWIW:
Tested-by: Daniel Thompson <[email protected]>
Daniel.
>
> Kyle, you seem to be pushing all this to the edge with RR, any clues?
>
> Since v2:
>
> - fixed (user) INT1 / icebp detection
> - some further cleanups
> - two additional RFC patches
>