From: Sean Christopherson <sean.j.christopherson@intel.com>
To: Andy Lutomirski <luto@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
X86 ML <x86@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>,
LKML <linux-kernel@vger.kernel.org>,
Rik van Riel <riel@surriel.com>,
Yu-cheng Yu <yu-cheng.yu@intel.com>,
Ingo Molnar <mingo@kernel.org>
Subject: Re: [PATCH v2] x86/fault: Decode and print #PF oops in human readable form
Date: Mon, 10 Dec 2018 08:04:27 -0800 [thread overview]
Message-ID: <20181210160427.GA15686@linux.intel.com> (raw)
In-Reply-To: <CALCETrUu=qO4tHkk-QxKD_j687hKV56X9JvYv1YsdgtOy0urmQ@mail.gmail.com>
On Fri, Dec 07, 2018 at 03:57:10PM -0800, Andy Lutomirski wrote:
> On Fri, Dec 7, 2018 at 2:14 PM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > On Fri, Dec 7, 2018 at 2:06 PM Sean Christopherson
> > <sean.j.christopherson@intel.com> wrote:
> > >
> > > Looking at it again, my own personal preference would be to swap the order
> > > of the #PF lines.
> >
> > Yeah, probably.
> >
> > Also:
> >
> > > [ 160.246820] BUG: unable to handle kernel paging request at ffffbeef00000000
> > > [ 160.247517] #PF: supervisor-privileged instruction fetch from kernel code
> > > [ 160.248085] #PF: error_code(0x0010) - not-present page
> >
> > With this form, I think the "kernel" in the first line is actually
> > misleading. Yes, it's a #PF for the kernel, but then the "kernel" on
> > the second line talks about what mode we were in when it happened, so
> > we have two different meanings of "kernel" on two adjacent lines.
>
> I'm okay with this variant. I have a slight preference for:
>
> #PF: supervisor-privileged instruction fetch from kernel code
> #PF error_code: 0x0010 [READ]
[INSTR], but I get the gist :)
> Which is what we'd get from Sean's patch plus my patch here:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/mm&id=ccfb1941f90153818c07fb1a7dc22121a970d252
>
> Sean, what do you think?
Munging the two concepts is my least favorite approach. Printing the
individual bits becomes redundant (with the first line) in many cases,
and superfluous in other cases, e.g. [PROT] is effectively implied by
[RSVD], [PK] and [SGX].
In the example above, printing "[INSTR]" doesn't provide any new info
since the line above already states it was an instruction fetch, and
it never provides a human-readable message describing *why* the fault
occurred.
It'd be more palatable if we printed the negative case for PROT, e.g.
"[!PROT]", but that re-opens the discussion on which bits should be
printed in the negative case. Like Ingo said, it's rather arbitrary
that USER=1 instead of SUPERVISOR=1.
> > So maybe that "BUG: unable to handle kernel paging request" message
> > should be something like
> >
> > "BUG: unable to handle page fault for address ffffbeef00000000"
> >
> > instead? Does that make sense to people?
>
> Yes please.
prev parent reply other threads:[~2018-12-10 16:04 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-05 16:36 [PATCH] x86/fault: Print "SUPERVISOR" and "READ" when decoding #PF oops Sean Christopherson
2018-12-05 19:27 ` Randy Dunlap
2018-12-05 19:35 ` Linus Torvalds
2018-12-06 7:34 ` [PATCH] x86/mm/fault: Streamline the fault error_code decoder some more Ingo Molnar
2018-12-06 15:53 ` Sean Christopherson
2018-12-06 16:23 ` Ingo Molnar
2018-12-06 16:39 ` Andy Lutomirski
2018-12-06 16:47 ` Ingo Molnar
2018-12-06 17:05 ` Andy Lutomirski
2018-12-06 17:36 ` Ingo Molnar
2018-12-06 18:15 ` Linus Torvalds
2018-12-06 19:06 ` Andy Lutomirski
2018-12-06 20:24 ` Linus Torvalds
2018-12-06 20:28 ` Andy Lutomirski
2018-12-06 20:39 ` Linus Torvalds
2018-12-07 18:44 ` [PATCH] x86/fault: Decode and print #PF oops in human readable form Sean Christopherson
2018-12-07 18:52 ` Linus Torvalds
2018-12-07 19:18 ` Sean Christopherson
2018-12-07 19:52 ` [PATCH v2] " Sean Christopherson
2018-12-07 20:46 ` Linus Torvalds
2018-12-07 22:06 ` Sean Christopherson
2018-12-07 22:14 ` Linus Torvalds
2018-12-07 23:57 ` Andy Lutomirski
2018-12-10 16:04 ` Sean Christopherson [this message]
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=20181210160427.GA15686@linux.intel.com \
--to=sean.j.christopherson@intel.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=riel@surriel.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.org \
--cc=yu-cheng.yu@intel.com \
/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