From: Dave Jones <davej@redhat.com>
To: Borislav Petkov <bp@alien8.de>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>, x86@kernel.org
Subject: Re: [x86] only print out DR registers if they are not power-on defaults.
Date: Tue, 18 Jun 2013 10:07:30 -0400 [thread overview]
Message-ID: <20130618140730.GA1313@redhat.com> (raw)
In-Reply-To: <20130618084356.GA13123@pd.tnic>
On Tue, Jun 18, 2013 at 10:43:56AM +0200, Borislav Petkov wrote:
> On Tue, Jun 18, 2013 at 12:11:32AM -0400, Dave Jones wrote:
> > The DR registers are rarely useful when decoding oopses.
> > With screen real estate during oopses at a premium, we can save two lines
> > by only printing out these registers when they are set to something other
> > than they power-on state.
>
> Makes sense, except...
>
> >
> > Signed-off-by: Dave Jones <davej@redhat.com>
> >
> > diff -durpN '--exclude-from=/home/davej/.exclude' /home/davej/src/kernel/git-trees/linux/arch/x86/kernel/process_64.c linux-dj/arch/x86/kernel/process_64.c
> > --- /home/davej/src/kernel/git-trees/linux/arch/x86/kernel/process_64.c 2013-05-01 10:02:52.064151923 -0400
> > +++ linux-dj/arch/x86/kernel/process_64.c 2013-05-06 20:35:09.219868881 -0400
> > @@ -105,11 +105,18 @@ void __show_regs(struct pt_regs *regs, i
> > get_debugreg(d0, 0);
> > get_debugreg(d1, 1);
> > get_debugreg(d2, 2);
> > - printk(KERN_DEFAULT "DR0: %016lx DR1: %016lx DR2: %016lx\n", d0, d1, d2);
> > get_debugreg(d3, 3);
> > get_debugreg(d6, 6);
> > get_debugreg(d7, 7);
> > +
> > + /* Only print out debug registers if they are in their non-default state. */
> > + if ((d0 == 0) && (d1 == 0) && (d2 == 0) && (d3 == 0) &&
> > + (d6 & ~DR6_RESERVED) && (d7 == 0x400))
>
> ... I'm not sure about %dr6. So we're not dumping %dr6 when, a.o.
> any of the bits in the bit slices [3:0], [15:13] are set (bit 12
> is Read-As-Zero). Now those mean stuff like Breakpoint-Condition
> Detected or Debug-Register-Access Detected and so on and I think this is
> meaningful information.
>
> So actually, we wouldn't want to dump %dr6 when its contents are its
> default contents, i.e, 0xffff0ff0, i.e. the test should be:
>
> (d6 == DR6_RESERVED)
>
> no?
My intent here was to ignore cases where the reserved bits haven't been set.
I occasionally see DR6: 00000000fffe0ff0 for eg.
But maybe you're right, and that is a clue and is worth printing ?
I can't personally recall ever diagnosing a bug using those register dumps
in the last 15 years.
Dave
next prev parent reply other threads:[~2013-06-18 14:08 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-18 4:11 [x86] only print out DR registers if they are not power-on defaults Dave Jones
2013-06-18 8:43 ` Borislav Petkov
2013-06-18 14:07 ` Dave Jones [this message]
2013-06-18 15:59 ` Borislav Petkov
2013-06-18 16:09 ` [x86][v2] " Dave Jones
2013-06-18 17:08 ` Borislav Petkov
2013-06-19 18:42 ` [tip:x86/debug] x86/debug: Only " tip-bot for Dave Jones
2013-06-19 21:42 ` [x86] only " H. Peter Anvin
2013-06-19 21:52 ` Borislav Petkov
2013-06-19 22:02 ` H. Peter Anvin
2013-06-20 5:29 ` Borislav Petkov
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=20130618140730.GA1313@redhat.com \
--to=davej@redhat.com \
--cc=bp@alien8.de \
--cc=linux-kernel@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).