From: "H. Peter Anvin" <hpa@zytor.com>
To: Jeff Merkey <linux.mdb@gmail.com>, linux-kernel@vger.kernel.org
Cc: Thomas Gleixner <tglx@linutronix.de>,
mingo@redhat.com, x86@kernel.org, peterz@infradead.org,
luto@kernel.org
Subject: Re: [PATCH] Fix int1 recursion with unregistered breakpoints
Date: Mon, 14 Dec 2015 13:39:38 -0800 [thread overview]
Message-ID: <566F371A.3090207@zytor.com> (raw)
In-Reply-To: <20151214210320.GA20856@localhost.localdomain>
On 12/14/15 13:03, Jeff Merkey wrote:
> Please consider the attached patch.
>
> I have reviewed all the code that touches this patch and have
> determined it will function and support all of the software that
> depends on this handler properly. I have compiled and tested this
> patch with a test harness that tests the robustness of the linux
> breakpoint API and handlers in the following ways:
>
> 1. Setting multiple conditional breakpoints through
> arch_install_hw_breakpoint API across four processors to test the rate
> at which the interface can handle breakpoint exceptions
>
> 2. Setting unregistered breakpoints to test the handlers robustness
> in dealing with error handling conditions and errant or spurious
> hardware conditions and to simulate actual "lazy debug register
> switching" (which does not work BTW) with null bp handlers to test the
> robustness of the handlers.
>
> 3. Clearing and setting breakpoints across multiple processors then
> triggering concurrent exceptions in both interrupt and process
> contexts.
>
> This patch improves robustness in several ways in the linux kernel:
>
> 1. Corrects bug in handling unregistered breakpoints.
>
> 2. Provides hardware check of dr7 to determine source of breakpoint
> if OS cannot ascertain the int1 source from its own state and
> variables.
>
> 3. Actually allows "lazy debug register switching" to function, which
> until recently has apparently never been actually seen on live
> hardware or actually tested.
>
This is all fine and good, but you are missing one of the most important
parts of a patch: a patch description, describing in detail the problem
that it solves and why. This description needs to be comprehensible not
just for people already initiated but for someone doing code archaeology
a decade from now.
Thanks,
-hpa
next prev parent reply other threads:[~2015-12-14 21:40 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-14 21:03 [PATCH] Fix int1 recursion with unregistered breakpoints Jeff Merkey
2015-12-14 21:39 ` H. Peter Anvin [this message]
2015-12-14 21:40 ` Jeff Merkey
-- strict thread matches above, loose matches on Subject: below --
2015-12-14 21:36 Jeff Merkey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=566F371A.3090207@zytor.com \
--to=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux.mdb@gmail.com \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.