Re: [PATCH 0/5] x86/dumpstack: Cleanups and user opcode bytes Code: section

[Borislav Petkov]

On Wed, Feb 21, 2018 at 01:39:52PM -0800, Linus Torvalds wrote:
> which are actually about the crash. The rest is almost entirely useless.
> 
> Do I know what the corrent answer is? No.

Ok, I hear ya. I finally have some time to poke at this. So here's a new
splat, see below. Incremental diff at the end:

RSP is part of the registers dump now, after the GPRs.

I've added "EXEC SUMMARY" markers for now, for ease of discussing
this. Will remove them later.

My silly idea is to save the first regs when we enter __die(), i.e.,
die_counter == 0 and dump them in oops_end() as an exec summary.

I guess we can expand that executive summary into a full-fledged
function which dumps everything critical needed to debug an issue.

Lemme read the rest of the thread now.

[   22.762334] sysrq: SysRq : Trigger a crash
[   22.763456] BUG: unable to handle kernel NULL pointer dereference at 

[   22.765416] PGD 7b64d067 P4D 7b64d067 PUD 79402067 PMD 0 
[   22.766121] Oops: 0002 [#1] PREEMPT SMP
[   22.766121] CPU: 0 PID: 3666 Comm: bash Not tainted 4.16.0-rc2+ #20
[   22.766121] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.10.2-1 04/01/2014
[   22.766121] RIP: 0010:sysrq_handle_crash+0x17/0x20
[   22.766121] Code: eb d1 e8 4d 19 b7 ff 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 
00 0f 1f 44 00 00 e8 96 27 bd ff c7 05 14 24 19 01 01 00 00 00 0f ae f8  04 
25 00 00 00 00 01 c3 0f 1f 44 00 00 e8 86 24 c2 ff fb e9 
[   22.766121] RAX:  RBX: 0063 RCX: 
[   22.766121] RDX:  RSI: 8110154a RDI: 0063
[   22.766121] RBP: 82271480 R08: 0185 R09: 000ba1de
[   22.766121] R10:  R11:  R12: 000a
[   22.766121] R13:  R14:  R15: 
[   22.766121] RSP: 0018:c9703df0 EFLAGS: 00010246
[   22.766121] FS:  77fdb700() GS:88007ec0() 
knlGS:
[   22.766121] CS:  0010 DS:  ES:  CR0: 80050033
[   22.766121] CR2:  CR3: 7b711000 CR4: 000406f0
[   22.766121] Call Trace:
[   22.766121]  __handle_sysrq+0x9e/0x160
[   22.766121]  write_sysrq_trigger+0x2b/0x30
[   22.766121]  proc_reg_write+0x38/0x70
[   22.766121]  __vfs_write+0x36/0x160
[   22.766121]  ? __fd_install+0x69/0x110
[   22.766121]  ? preempt_count_add+0x74/0xb0
[   22.766121]  ? _raw_spin_lock+0x13/0x30
[   22.766121]  ? set_close_on_exec+0x41/0x80
[   22.766121]  ? preempt_count_sub+0xa8/0x100
[   22.766121]  vfs_write+0xc0/0x190
[   22.766121]  SyS_write+0x64/0xe0
[   22.766121]  ? trace_hardirqs_off_thunk+0x1a/0x1c
[   22.766121]  do_syscall_64+0x70/0x130
[   22.766121]  entry_SYSCALL_64_after_hwframe+0x42/0xb7
[   22.766121] RIP: 0033:0x774b9620
[   22.766121] Code: ff 73 01 c3 48 8b 0d 68 98 2c 00 f7 d8 64 89 01 48 83 c8 
ff c3 66 0f 1f 44 00 00 83 3d bd f1 2c 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 
01 f0 ff ff 73 31 c3 48 83 ec 08 e8 ce 8f 01 00 48 89 04 
[   22.766121]  ORIG_RAX: 0001
[   22.766121] RAX: ffda RBX: 0002 RCX: 774b9620
[   22.766121] RDX: 0002 RSI: 00705408 RDI: 0001
[   22.766121] RBP: 00705408 R08: 000a R09: 77fdb700
[   22.766121] R10: 7fffe490 R11: 0246 R12: 777842a0
[   22.766121] R13: 0002 R14: 0001 R15: 
[   22.766121] RSP: 002b:7fffe638 EFLAGS: 0246
[   22.766121] Modules linked in:
[   22.766121] CR2: 
[   22.817404] ---[ end trace 374137bfd9ca49cc ]---
[   22.818727] :
[   22.819608] RIP: 0010:sysrq_handle_crash+0x17/0x20
[   22.820906] Code: eb d1 e8 4d 19 b7 ff 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 
00 0f 1f 44 00 00 e8 96 27 bd ff c7 05 14 24 19 01 01 00 00 00 0f ae f8  04 
25 00 00 00 00 01 c3 0f 1f 44 00 00 e8 86 24 c2 ff fb e9 
[   22.824896] RAX:  RBX: 0063 RCX: 
[   22.826208] RDX:  RSI: 8110154a RDI: 0063
[   22.827506] RBP: 82271480 R08: 0185 R09: 000ba1de
[   22.828935] R10:  R11:  R12: 000a
[   22.830257] R13:  R14:  R15: 
[   22.831535] RSP: 0018:c9703df0 EFLAGS: 00010246
[   22.831536] :
[   22.836493] Kernel panic - not syncing: Fatal exception
[   22.837871] Kernel Offset: disabled
[   22.838648] ---[ end Kernel panic - not syncing: Fatal exception


---
diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpstack.c
index 0037bdc9e252..e71319194f6c 100644
--- a/arch/x86/kernel/dumpstack.c
+++ b/arch/x86/kernel/dumpstack.c
@@ -31,6 +31,8 @@ static u8 __opc[OPCODE_BUFSIZE];
 static u8 *opcodes = __opc;
 static int die_counter;
 
+static struct pt_regs exec_summary_regs;
+
 bool in_task_stack(unsigned long *stack, struct 

Re: [PATCH 0/5] x86/dumpstack: Cleanups and user opcode bytes Code: section

[Borislav Petkov]

On Wed, Feb 21, 2018 at 01:39:52PM -0800, Linus Torvalds wrote:
> which are actually about the crash. The rest is almost entirely useless.
> 
> Do I know what the corrent answer is? No.

Ok, I hear ya. I finally have some time to poke at this. So here's a new
splat, see below. Incremental diff at the end:

RSP is part of the registers dump now, after the GPRs.

I've added "EXEC SUMMARY" markers for now, for ease of discussing
this. Will remove them later.

My silly idea is to save the first regs when we enter __die(), i.e.,
die_counter == 0 and dump them in oops_end() as an exec summary.

I guess we can expand that executive summary into a full-fledged
function which dumps everything critical needed to debug an issue.

Lemme read the rest of the thread now.

[   22.762334] sysrq: SysRq : Trigger a crash
[   22.763456] BUG: unable to handle kernel NULL pointer dereference at 

[   22.765416] PGD 7b64d067 P4D 7b64d067 PUD 79402067 PMD 0 
[   22.766121] Oops: 0002 [#1] PREEMPT SMP
[   22.766121] CPU: 0 PID: 3666 Comm: bash Not tainted 4.16.0-rc2+ #20
[   22.766121] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.10.2-1 04/01/2014
[   22.766121] RIP: 0010:sysrq_handle_crash+0x17/0x20
[   22.766121] Code: eb d1 e8 4d 19 b7 ff 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 
00 0f 1f 44 00 00 e8 96 27 bd ff c7 05 14 24 19 01 01 00 00 00 0f ae f8  04 
25 00 00 00 00 01 c3 0f 1f 44 00 00 e8 86 24 c2 ff fb e9 
[   22.766121] RAX:  RBX: 0063 RCX: 
[   22.766121] RDX:  RSI: 8110154a RDI: 0063
[   22.766121] RBP: 82271480 R08: 0185 R09: 000ba1de
[   22.766121] R10:  R11:  R12: 000a
[   22.766121] R13:  R14:  R15: 
[   22.766121] RSP: 0018:c9703df0 EFLAGS: 00010246
[   22.766121] FS:  77fdb700() GS:88007ec0() 
knlGS:
[   22.766121] CS:  0010 DS:  ES:  CR0: 80050033
[   22.766121] CR2:  CR3: 7b711000 CR4: 000406f0
[   22.766121] Call Trace:
[   22.766121]  __handle_sysrq+0x9e/0x160
[   22.766121]  write_sysrq_trigger+0x2b/0x30
[   22.766121]  proc_reg_write+0x38/0x70
[   22.766121]  __vfs_write+0x36/0x160
[   22.766121]  ? __fd_install+0x69/0x110
[   22.766121]  ? preempt_count_add+0x74/0xb0
[   22.766121]  ? _raw_spin_lock+0x13/0x30
[   22.766121]  ? set_close_on_exec+0x41/0x80
[   22.766121]  ? preempt_count_sub+0xa8/0x100
[   22.766121]  vfs_write+0xc0/0x190
[   22.766121]  SyS_write+0x64/0xe0
[   22.766121]  ? trace_hardirqs_off_thunk+0x1a/0x1c
[   22.766121]  do_syscall_64+0x70/0x130
[   22.766121]  entry_SYSCALL_64_after_hwframe+0x42/0xb7
[   22.766121] RIP: 0033:0x774b9620
[   22.766121] Code: ff 73 01 c3 48 8b 0d 68 98 2c 00 f7 d8 64 89 01 48 83 c8 
ff c3 66 0f 1f 44 00 00 83 3d bd f1 2c 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 
01 f0 ff ff 73 31 c3 48 83 ec 08 e8 ce 8f 01 00 48 89 04 
[   22.766121]  ORIG_RAX: 0001
[   22.766121] RAX: ffda RBX: 0002 RCX: 774b9620
[   22.766121] RDX: 0002 RSI: 00705408 RDI: 0001
[   22.766121] RBP: 00705408 R08: 000a R09: 77fdb700
[   22.766121] R10: 7fffe490 R11: 0246 R12: 777842a0
[   22.766121] R13: 0002 R14: 0001 R15: 
[   22.766121] RSP: 002b:7fffe638 EFLAGS: 0246
[   22.766121] Modules linked in:
[   22.766121] CR2: 
[   22.817404] ---[ end trace 374137bfd9ca49cc ]---
[   22.818727] :
[   22.819608] RIP: 0010:sysrq_handle_crash+0x17/0x20
[   22.820906] Code: eb d1 e8 4d 19 b7 ff 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 
00 0f 1f 44 00 00 e8 96 27 bd ff c7 05 14 24 19 01 01 00 00 00 0f ae f8  04 
25 00 00 00 00 01 c3 0f 1f 44 00 00 e8 86 24 c2 ff fb e9 
[   22.824896] RAX:  RBX: 0063 RCX: 
[   22.826208] RDX:  RSI: 8110154a RDI: 0063
[   22.827506] RBP: 82271480 R08: 0185 R09: 000ba1de
[   22.828935] R10:  R11:  R12: 000a
[   22.830257] R13:  R14:  R15: 
[   22.831535] RSP: 0018:c9703df0 EFLAGS: 00010246
[   22.831536] :
[   22.836493] Kernel panic - not syncing: Fatal exception
[   22.837871] Kernel Offset: disabled
[   22.838648] ---[ end Kernel panic - not syncing: Fatal exception


---
diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpstack.c
index 0037bdc9e252..e71319194f6c 100644
--- a/arch/x86/kernel/dumpstack.c
+++ b/arch/x86/kernel/dumpstack.c
@@ -31,6 +31,8 @@ static u8 __opc[OPCODE_BUFSIZE];
 static u8 *opcodes = __opc;
 static int die_counter;
 
+static struct pt_regs exec_summary_regs;
+
 bool in_task_stack(unsigned long *stack, struct 

Re: [PATCH 0/5] x86/dumpstack: Cleanups and user opcode bytes Code: section

[Eric W. Biederman]

Josh Poimboeuf  writes:

> On Thu, Feb 22, 2018 at 10:42:52AM -0800, Linus Torvalds wrote:
>> So what we could perhaps do is:
>> 
>>  - make console_verbose() actually reset things to at least LOGLEVEL_DEBUG
>> 
>>  - make sure the *default* loglevel  be LOGLEVEL_WARNING
>> 
>>  - now you can use pr_debug() in the oops code to print messages to
>> the log, but they won't be printed to the screen.
>> 
>> And people who really want everything can still set a loglevel that is
>> much higher, because "console_verbose" would only do that "at least"
>> thing.
>> 
>> That would seem like the best of both worlds, no?
>
> Maybe.
>
> Broadly speaking, I think our goal should be, in the worst case, to try
> to ensure that the essential data is captured.
>
> But the definitions of "worst case" and "essential data" can vary a lot,
> depending on both the user's setup and the nature of the bug.  We're not
> going to be able to get it right 100% of the time.
>
> You're assuming the worst case of
>
>   "an 80x25 screen is the only interface to the console".
>
> But there's another worst case of
>
>   "we had unlimited serial port logging, but didn't dump enough data".
>
> With your proposal, the latter might instead become:
>
>   "we had unlimited serial port logging, but didn't dump enough data
>because the default loglevel was too low."
>
> I did a little analysis of panics reported on lkml via .jpg files
> (either attached or in a URL).  In the last two years I only found 11
> such reports.  (And only two of them were 25x80, the rest were at least
> 47 rows.)
>
> On the other hand, I found a *ton* of panics which were copy/pasted.  It
> was way too many to count, but a rough guess is about one per day.
>
> So ~1.5% of bugs are reported via cell phone camera (with only about
> 5-10% of *those* on a tiny 25x80 screen, with the rest having at least
> 47 rows).
>
> It's not very scientific, but it gives a general idea, I think.  The
> cell phone camera thing has become a pretty rare way to report bugs, and
> with the proliferation of virtualization and automated testing I would
> expect that trend to continue.
>
> So my worry with your proposal is that many (or most?) people won't
> change their default log level to DEBUG, and then all these nice
> additional bits of data we're adding won't ever get printed, making
> debug harder for the ~98.5% case of sane serial port logging.
>
> But then again, I don't have any better ideas...

Please also note there are serial ports and there are serials ports.
There are serial ports on virtual machines that don't have a speed.
Then there are serial ports on physical hardware some at 9600 baud,
and in all cases they are slow.  So on a physical serial port tersness
is a virtue (unless the machine is completely dead).

Then we have panics and the like that are reported by kdump.  Those
should be cut and pastable as well.  But require that someone has done
the work to set that up so that is a reliable path.

I know that in working on kexec-on-panic what I have found is the less
code in a critical path you have to run in a b0rken kernel the higher
your chance of that code running successfully.  I expect that applies
to the panic printer as much as anything else.

Eric

Re: [PATCH 0/5] x86/dumpstack: Cleanups and user opcode bytes Code: section

[Eric W. Biederman]

Josh Poimboeuf  writes:

> On Thu, Feb 22, 2018 at 10:42:52AM -0800, Linus Torvalds wrote:
>> So what we could perhaps do is:
>> 
>>  - make console_verbose() actually reset things to at least LOGLEVEL_DEBUG
>> 
>>  - make sure the *default* loglevel  be LOGLEVEL_WARNING
>> 
>>  - now you can use pr_debug() in the oops code to print messages to
>> the log, but they won't be printed to the screen.
>> 
>> And people who really want everything can still set a loglevel that is
>> much higher, because "console_verbose" would only do that "at least"
>> thing.
>> 
>> That would seem like the best of both worlds, no?
>
> Maybe.
>
> Broadly speaking, I think our goal should be, in the worst case, to try
> to ensure that the essential data is captured.
>
> But the definitions of "worst case" and "essential data" can vary a lot,
> depending on both the user's setup and the nature of the bug.  We're not
> going to be able to get it right 100% of the time.
>
> You're assuming the worst case of
>
>   "an 80x25 screen is the only interface to the console".
>
> But there's another worst case of
>
>   "we had unlimited serial port logging, but didn't dump enough data".
>
> With your proposal, the latter might instead become:
>
>   "we had unlimited serial port logging, but didn't dump enough data
>because the default loglevel was too low."
>
> I did a little analysis of panics reported on lkml via .jpg files
> (either attached or in a URL).  In the last two years I only found 11
> such reports.  (And only two of them were 25x80, the rest were at least
> 47 rows.)
>
> On the other hand, I found a *ton* of panics which were copy/pasted.  It
> was way too many to count, but a rough guess is about one per day.
>
> So ~1.5% of bugs are reported via cell phone camera (with only about
> 5-10% of *those* on a tiny 25x80 screen, with the rest having at least
> 47 rows).
>
> It's not very scientific, but it gives a general idea, I think.  The
> cell phone camera thing has become a pretty rare way to report bugs, and
> with the proliferation of virtualization and automated testing I would
> expect that trend to continue.
>
> So my worry with your proposal is that many (or most?) people won't
> change their default log level to DEBUG, and then all these nice
> additional bits of data we're adding won't ever get printed, making
> debug harder for the ~98.5% case of sane serial port logging.
>
> But then again, I don't have any better ideas...

Please also note there are serial ports and there are serials ports.
There are serial ports on virtual machines that don't have a speed.
Then there are serial ports on physical hardware some at 9600 baud,
and in all cases they are slow.  So on a physical serial port tersness
is a virtue (unless the machine is completely dead).

Then we have panics and the like that are reported by kdump.  Those
should be cut and pastable as well.  But require that someone has done
the work to set that up so that is a reliable path.

I know that in working on kexec-on-panic what I have found is the less
code in a critical path you have to run in a b0rken kernel the higher
your chance of that code running successfully.  I expect that applies
to the panic printer as much as anything else.

Eric

Re: [PATCH 0/5] x86/dumpstack: Cleanups and user opcode bytes Code: section

[Josh Poimboeuf]

On Thu, Feb 22, 2018 at 10:42:52AM -0800, Linus Torvalds wrote:
> So what we could perhaps do is:
> 
>  - make console_verbose() actually reset things to at least LOGLEVEL_DEBUG
> 
>  - make sure the *default* loglevel  be LOGLEVEL_WARNING
> 
>  - now you can use pr_debug() in the oops code to print messages to
> the log, but they won't be printed to the screen.
> 
> And people who really want everything can still set a loglevel that is
> much higher, because "console_verbose" would only do that "at least"
> thing.
> 
> That would seem like the best of both worlds, no?

Maybe.

Broadly speaking, I think our goal should be, in the worst case, to try
to ensure that the essential data is captured.

But the definitions of "worst case" and "essential data" can vary a lot,
depending on both the user's setup and the nature of the bug.  We're not
going to be able to get it right 100% of the time.

You're assuming the worst case of

  "an 80x25 screen is the only interface to the console".

But there's another worst case of

  "we had unlimited serial port logging, but didn't dump enough data".

With your proposal, the latter might instead become:

  "we had unlimited serial port logging, but didn't dump enough data
   because the default loglevel was too low."

I did a little analysis of panics reported on lkml via .jpg files
(either attached or in a URL).  In the last two years I only found 11
such reports.  (And only two of them were 25x80, the rest were at least
47 rows.)

On the other hand, I found a *ton* of panics which were copy/pasted.  It
was way too many to count, but a rough guess is about one per day.

So ~1.5% of bugs are reported via cell phone camera (with only about
5-10% of *those* on a tiny 25x80 screen, with the rest having at least
47 rows).

It's not very scientific, but it gives a general idea, I think.  The
cell phone camera thing has become a pretty rare way to report bugs, and
with the proliferation of virtualization and automated testing I would
expect that trend to continue.

So my worry with your proposal is that many (or most?) people won't
change their default log level to DEBUG, and then all these nice
additional bits of data we're adding won't ever get printed, making
debug harder for the ~98.5% case of sane serial port logging.

But then again, I don't have any better ideas...

-- 
Josh

Re: [PATCH 0/5] x86/dumpstack: Cleanups and user opcode bytes Code: section

[Josh Poimboeuf]

On Thu, Feb 22, 2018 at 10:42:52AM -0800, Linus Torvalds wrote:
> So what we could perhaps do is:
> 
>  - make console_verbose() actually reset things to at least LOGLEVEL_DEBUG
> 
>  - make sure the *default* loglevel  be LOGLEVEL_WARNING
> 
>  - now you can use pr_debug() in the oops code to print messages to
> the log, but they won't be printed to the screen.
> 
> And people who really want everything can still set a loglevel that is
> much higher, because "console_verbose" would only do that "at least"
> thing.
> 
> That would seem like the best of both worlds, no?

Maybe.

Broadly speaking, I think our goal should be, in the worst case, to try
to ensure that the essential data is captured.

But the definitions of "worst case" and "essential data" can vary a lot,
depending on both the user's setup and the nature of the bug.  We're not
going to be able to get it right 100% of the time.

You're assuming the worst case of

  "an 80x25 screen is the only interface to the console".

But there's another worst case of

  "we had unlimited serial port logging, but didn't dump enough data".

With your proposal, the latter might instead become:

  "we had unlimited serial port logging, but didn't dump enough data
   because the default loglevel was too low."

I did a little analysis of panics reported on lkml via .jpg files
(either attached or in a URL).  In the last two years I only found 11
such reports.  (And only two of them were 25x80, the rest were at least
47 rows.)

On the other hand, I found a *ton* of panics which were copy/pasted.  It
was way too many to count, but a rough guess is about one per day.

So ~1.5% of bugs are reported via cell phone camera (with only about
5-10% of *those* on a tiny 25x80 screen, with the rest having at least
47 rows).

It's not very scientific, but it gives a general idea, I think.  The
cell phone camera thing has become a pretty rare way to report bugs, and
with the proliferation of virtualization and automated testing I would
expect that trend to continue.

So my worry with your proposal is that many (or most?) people won't
change their default log level to DEBUG, and then all these nice
additional bits of data we're adding won't ever get printed, making
debug harder for the ~98.5% case of sane serial port logging.

But then again, I don't have any better ideas...

-- 
Josh

Re: [PATCH 0/5] x86/dumpstack: Cleanups and user opcode bytes Code: section

[Linus Torvalds]

On Thu, Feb 22, 2018 at 1:23 AM, Peter Zijlstra  wrote:
>
> So being one to only use machines that have a serial line this does not
> really affect me; but it would appear to me that it might make sense to
> try and reverse the entire dump.

In theory yes. But while you mention the buffering problem, the
*bigger* problem is that sometimes things go south half-way through.
We've definitely had cases where we only get the first few lines of
the oops, because the oops machinery itself has issues (ie takes a
fault in the middle because of random corruption issues or the stack
tracing acting up or whatever).

So while "most important last" is good for it not scrolling off the
screen, it's really bad for the "oops itself has problems" case.

I'd rather people try very hard to make the oops messages dense and
relevant, and not have information that isn't really useful in
practice. We already got rid of the stack content dumping for that
reason - it was useful 20+ years ago, but it had become more of a
detriment than a real help.

So I don't want people to think "this _might_ be useful, let's print
it out". It really should be "this is _critically_ useful, it's worth
printing out even if we're limited to a 80x25 screen".

Honestly, I think one option is to just mark parts for "printing" and
other parts for "logging". I think we may raise the loglevel a bit
_too_ much when an oops happens in "console_verbose()".

So what we could perhaps do is:

 - make console_verbose() actually reset things to at least LOGLEVEL_DEBUG

 - make sure the *default* loglevel  be LOGLEVEL_WARNING

 - now you can use pr_debug() in the oops code to print messages to
the log, but they won't be printed to the screen.

And people who really want everything can still set a loglevel that is
much higher, because "console_verbose" would only do that "at least"
thing.

That would seem like the best of both worlds, no?

  Linus

Re: [PATCH 0/5] x86/dumpstack: Cleanups and user opcode bytes Code: section

[Linus Torvalds]

On Thu, Feb 22, 2018 at 1:23 AM, Peter Zijlstra  wrote:
>
> So being one to only use machines that have a serial line this does not
> really affect me; but it would appear to me that it might make sense to
> try and reverse the entire dump.

In theory yes. But while you mention the buffering problem, the
*bigger* problem is that sometimes things go south half-way through.
We've definitely had cases where we only get the first few lines of
the oops, because the oops machinery itself has issues (ie takes a
fault in the middle because of random corruption issues or the stack
tracing acting up or whatever).

So while "most important last" is good for it not scrolling off the
screen, it's really bad for the "oops itself has problems" case.

I'd rather people try very hard to make the oops messages dense and
relevant, and not have information that isn't really useful in
practice. We already got rid of the stack content dumping for that
reason - it was useful 20+ years ago, but it had become more of a
detriment than a real help.

So I don't want people to think "this _might_ be useful, let's print
it out". It really should be "this is _critically_ useful, it's worth
printing out even if we're limited to a 80x25 screen".

Honestly, I think one option is to just mark parts for "printing" and
other parts for "logging". I think we may raise the loglevel a bit
_too_ much when an oops happens in "console_verbose()".

So what we could perhaps do is:

 - make console_verbose() actually reset things to at least LOGLEVEL_DEBUG

 - make sure the *default* loglevel  be LOGLEVEL_WARNING

 - now you can use pr_debug() in the oops code to print messages to
the log, but they won't be printed to the screen.

And people who really want everything can still set a loglevel that is
much higher, because "console_verbose" would only do that "at least"
thing.

That would seem like the best of both worlds, no?

  Linus

Re: [PATCH 0/5] x86/dumpstack: Cleanups and user opcode bytes Code: section

[Peter Zijlstra]

On Wed, Feb 21, 2018 at 01:39:52PM -0800, Linus Torvalds wrote:
> showing with a hung kernel. And most of the above is actually
> completely useless. Those are the *usermode* registers it shows, not
> the kernel registers at the time of the crash (the final rip/rsp/code
> lines are for the actual kernel crash, but I'm talking about the
> register dump above it).
> 
> So notice how most of the *useful* data has actually scrolled off the
> screen and is all gone because the machine is hung. Instead, we've
> added stuff that doesn't help at all, usually.
> 
> It's not just that last patch, obviously. The big hunk o fuser
> register dumping is actually from Josh's trace improvements. But the
> above really is a great example of how we have made oopses *harder* to
> read by trying to add more data. They have gotten messier, but they
> have also gotten so verbose that the *good* stuff has all scrolled
> away.
> 
> So I think we should take a hard look at that "more data is better".
> Look at the above 25 lines and tell me - is that actually 25 useful
> lines for debugging a crash in sysrq_handle_crash?

So being one to only use machines that have a serial line this does not
really affect me; but it would appear to me that it might make sense to
try and reverse the entire dump.

That is 'obviously' going to be rather tricky, because we'll have to
print in the direct reverse direction we discover the data and the only
way to do that is with extra buffers, which adds extra complexity to
something we want absolutely robust.

But a simply line based reverse of the output would get us the most
useful data last, just what we want.

Re: [PATCH 0/5] x86/dumpstack: Cleanups and user opcode bytes Code: section

[Peter Zijlstra]

On Wed, Feb 21, 2018 at 01:39:52PM -0800, Linus Torvalds wrote:
> showing with a hung kernel. And most of the above is actually
> completely useless. Those are the *usermode* registers it shows, not
> the kernel registers at the time of the crash (the final rip/rsp/code
> lines are for the actual kernel crash, but I'm talking about the
> register dump above it).
> 
> So notice how most of the *useful* data has actually scrolled off the
> screen and is all gone because the machine is hung. Instead, we've
> added stuff that doesn't help at all, usually.
> 
> It's not just that last patch, obviously. The big hunk o fuser
> register dumping is actually from Josh's trace improvements. But the
> above really is a great example of how we have made oopses *harder* to
> read by trying to add more data. They have gotten messier, but they
> have also gotten so verbose that the *good* stuff has all scrolled
> away.
> 
> So I think we should take a hard look at that "more data is better".
> Look at the above 25 lines and tell me - is that actually 25 useful
> lines for debugging a crash in sysrq_handle_crash?

So being one to only use machines that have a serial line this does not
really affect me; but it would appear to me that it might make sense to
try and reverse the entire dump.

That is 'obviously' going to be rather tricky, because we'll have to
print in the direct reverse direction we discover the data and the only
way to do that is with extra buffers, which adds extra complexity to
something we want absolutely robust.

But a simply line based reverse of the output would get us the most
useful data last, just what we want.

Re: [PATCH 0/5] x86/dumpstack: Cleanups and user opcode bytes Code: section

[Linus Torvalds]

On Wed, Feb 21, 2018 at 9:54 AM, Borislav Petkov  wrote:
>
> Ok, lemme run it by Linus too as he probably stares at this part of the
> output a *lot* :-)

Less than I used to, since there are others who are pretty good at
decoding them, but yes...

> Anyway, here's a 64-bit splat. I'm basically dumping opcode bytes
> everytime we dump RIP.

So I think that's probably a good idea, but the way it ends up being
repeated is really confusing. Particularly when you now do it for the
user code too - which might be occasionally useful, but your example
also shows how there are now _three_ code lines due to the duplication
at the end (for "maybe the first one scrolled off the screen" and the
user code).

And the "executive summary" used to be a dense one-liner (to not
scroll the non-summary away), now it's generally four lines on the
screen (you also made the RIP/RSP be now two lines, and the Code line
is usually two lines because it's so long).

So my gut feel is that yes, this is moving in the right direction, but
I also really think that it now makes the normal oops too big to fit
on a screen.

That matters, because we still end up having the "take a picture of
the oops" issue for hard hangs etc that don't survive in the logs.

Do I know what the right answer is? No. But I suspect at the very
least we would want to get rid of the RSP line from show_ip(), and
make that part of the regular regs. That would make the summary one
line less.

Hmm. The Code: line actually ends up being *three* lines on the
default 80x25 screen, so in your 64-bit example, you actually get
something like this:

 ? preempt_count_sub+0xa8/0x100
 vfs_write+0xc0/0x190
 SyS_write+0x64/0xe0
 ? trace_hardirqs_off_thunk+0x1a/0x1c
 do_syscall_64+0x76/0x140
 entry_SYSCALL_64_after_hwframe+0x42/0xb7
RIP: 0033:0x774b9620
RSP: 002b:7fffe7a8 EFLAGS: 0246
Code: ff 73 01 c3 48 8b 0d 68 98 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66
0f 1f 44 00 00 83 3d bd f1 2c 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d
01 f0 ff ff 73 31 c3 48 83 ec 08 e8 ce 8f 01 00 48 89 04
 ORIG_RAX: 0001
RAX: ffda RBX: 0002 RCX: 774b9620
RDX: 0002 RSI: 00705408 RDI: 0001
RBP: 00705408 R08: 000a R09: 77fdb700
R10: 777826a0 R11: 0246 R12: 777842a0
R13: 0002 R14: 0001 R15: 
RIP: 0010:sysrq_handle_crash+0x17/0x20
RSP: 0018:c9c23df0 EFLAGS: 00010246
Code: eb d1 e8 fd ca b6 ff 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f
44 00 00 e8 f6 de bc ff c7 05 84 0d 1a 01 01 00 00 00 0f ae f8  04
25 00 00 00 00 01 c3 0f 1f 44 00 00 e8 86 df c1 ff fb 66
CR2: 
---[ end trace e17dc9a4aa5cc4d9 ]---
Kernel panic - not syncing: Fatal exception

showing with a hung kernel. And most of the above is actually
completely useless. Those are the *usermode* registers it shows, not
the kernel registers at the time of the crash (the final rip/rsp/code
lines are for the actual kernel crash, but I'm talking about the
register dump above it).

So notice how most of the *useful* data has actually scrolled off the
screen and is all gone because the machine is hung. Instead, we've
added stuff that doesn't help at all, usually.

It's not just that last patch, obviously. The big hunk o fuser
register dumping is actually from Josh's trace improvements. But the
above really is a great example of how we have made oopses *harder* to
read by trying to add more data. They have gotten messier, but they
have also gotten so verbose that the *good* stuff has all scrolled
away.

So I think we should take a hard look at that "more data is better".
Look at the above 25 lines and tell me - is that actually 25 useful
lines for debugging a crash in sysrq_handle_crash?

No. The only really _useful_ lines above are

RIP: 0010:sysrq_handle_crash+0x17/0x20
RSP: 0018:c9c23df0 EFLAGS: 00010246
Code: eb d1 e8 fd ca b6 ff 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f
44 00 00 e8 f6 de bc ff c7 05 84 0d 1a 01 01 00 00 00 0f ae f8  04
25 00 00 00 00 01 c3 0f 1f 44 00 00 e8 86 df c1 ff fb 66
CR2: 

which are actually about the crash. The rest is almost entirely useless.

Do I know what the corrent answer is? No.

  Linus

Re: [PATCH 0/5] x86/dumpstack: Cleanups and user opcode bytes Code: section

[Linus Torvalds]

On Wed, Feb 21, 2018 at 9:54 AM, Borislav Petkov  wrote:
>
> Ok, lemme run it by Linus too as he probably stares at this part of the
> output a *lot* :-)

Less than I used to, since there are others who are pretty good at
decoding them, but yes...

> Anyway, here's a 64-bit splat. I'm basically dumping opcode bytes
> everytime we dump RIP.

So I think that's probably a good idea, but the way it ends up being
repeated is really confusing. Particularly when you now do it for the
user code too - which might be occasionally useful, but your example
also shows how there are now _three_ code lines due to the duplication
at the end (for "maybe the first one scrolled off the screen" and the
user code).

And the "executive summary" used to be a dense one-liner (to not
scroll the non-summary away), now it's generally four lines on the
screen (you also made the RIP/RSP be now two lines, and the Code line
is usually two lines because it's so long).

So my gut feel is that yes, this is moving in the right direction, but
I also really think that it now makes the normal oops too big to fit
on a screen.

That matters, because we still end up having the "take a picture of
the oops" issue for hard hangs etc that don't survive in the logs.

Do I know what the right answer is? No. But I suspect at the very
least we would want to get rid of the RSP line from show_ip(), and
make that part of the regular regs. That would make the summary one
line less.

Hmm. The Code: line actually ends up being *three* lines on the
default 80x25 screen, so in your 64-bit example, you actually get
something like this:

 ? preempt_count_sub+0xa8/0x100
 vfs_write+0xc0/0x190
 SyS_write+0x64/0xe0
 ? trace_hardirqs_off_thunk+0x1a/0x1c
 do_syscall_64+0x76/0x140
 entry_SYSCALL_64_after_hwframe+0x42/0xb7
RIP: 0033:0x774b9620
RSP: 002b:7fffe7a8 EFLAGS: 0246
Code: ff 73 01 c3 48 8b 0d 68 98 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66
0f 1f 44 00 00 83 3d bd f1 2c 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d
01 f0 ff ff 73 31 c3 48 83 ec 08 e8 ce 8f 01 00 48 89 04
 ORIG_RAX: 0001
RAX: ffda RBX: 0002 RCX: 774b9620
RDX: 0002 RSI: 00705408 RDI: 0001
RBP: 00705408 R08: 000a R09: 77fdb700
R10: 777826a0 R11: 0246 R12: 777842a0
R13: 0002 R14: 0001 R15: 
RIP: 0010:sysrq_handle_crash+0x17/0x20
RSP: 0018:c9c23df0 EFLAGS: 00010246
Code: eb d1 e8 fd ca b6 ff 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f
44 00 00 e8 f6 de bc ff c7 05 84 0d 1a 01 01 00 00 00 0f ae f8  04
25 00 00 00 00 01 c3 0f 1f 44 00 00 e8 86 df c1 ff fb 66
CR2: 
---[ end trace e17dc9a4aa5cc4d9 ]---
Kernel panic - not syncing: Fatal exception

showing with a hung kernel. And most of the above is actually
completely useless. Those are the *usermode* registers it shows, not
the kernel registers at the time of the crash (the final rip/rsp/code
lines are for the actual kernel crash, but I'm talking about the
register dump above it).

So notice how most of the *useful* data has actually scrolled off the
screen and is all gone because the machine is hung. Instead, we've
added stuff that doesn't help at all, usually.

It's not just that last patch, obviously. The big hunk o fuser
register dumping is actually from Josh's trace improvements. But the
above really is a great example of how we have made oopses *harder* to
read by trying to add more data. They have gotten messier, but they
have also gotten so verbose that the *good* stuff has all scrolled
away.

So I think we should take a hard look at that "more data is better".
Look at the above 25 lines and tell me - is that actually 25 useful
lines for debugging a crash in sysrq_handle_crash?

No. The only really _useful_ lines above are

RIP: 0010:sysrq_handle_crash+0x17/0x20
RSP: 0018:c9c23df0 EFLAGS: 00010246
Code: eb d1 e8 fd ca b6 ff 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f
44 00 00 e8 f6 de bc ff c7 05 84 0d 1a 01 01 00 00 00 0f ae f8  04
25 00 00 00 00 01 c3 0f 1f 44 00 00 e8 86 df c1 ff fb 66
CR2: 

which are actually about the crash. The rest is almost entirely useless.

Do I know what the corrent answer is? No.

  Linus

Re: [PATCH 0/5] x86/dumpstack: Cleanups and user opcode bytes Code: section

[Borislav Petkov]

On Wed, Feb 21, 2018 at 10:15:53AM +0100, Ingo Molnar wrote:
> That looks really useful!

Ok, lemme run it by Linus too as he probably stares at this part of the
output a *lot* :-)

Combined patch at the end. I'll split it later.

@Linus: also, pls have a look at
https://lkml.kernel.org/r/20180219202826.19797-6...@alien8.de

I've added Code: section to user faults too because there might be
some usefulness in seeing the user opcode bytes when it faults. Some
arguments in the commit message there.

Anyway, here's a 64-bit splat. I'm basically dumping opcode bytes
everytime we dump RIP.

[   18.304872] sysrq: SysRq : Trigger a crash
[   18.306961] BUG: unable to handle kernel NULL pointer dereference at 
  (null)
[   18.310702] IP: sysrq_handle_crash+0x17/0x20
[   18.312830] PGD 7a972067 P4D 7a972067 PUD 7a351067 PMD 0 
[   18.316431] Oops: 0002 [#1] PREEMPT SMP
[   18.317219] Modules linked in:
[   18.317865] CPU: 6 PID: 3681 Comm: bash Not tainted 4.16.0-rc1+ #14
[   18.319237] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.10.2-1 04/01/2014
[   18.321162] RIP: 0010:sysrq_handle_crash+0x17/0x20
[   18.322273] RSP: 0018:c9c23df0 EFLAGS: 00010246
[   18.322274] Code: eb d1 e8 fd ca b6 ff 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 
00 0f 1f 44 00 00 e8 f6 de bc ff c7 05 84 0d 1a 01 01 00 00 00 0f ae f8  04 
25 00 00 00 00 01 c3 0f 1f 44 00 00 e8 86 df c1 ff fb 66 
[   18.331362] RAX:  RBX: 0063 RCX: 
[   18.332660] RDX:  RSI: 81103293 RDI: 0063
[   18.333931] RBP: 82271880 R08: 01a4 R09: 0004a6e8
[   18.335209] R10:  R11:  R12: 000a
[   18.336874] R13:  R14:  R15: 
[   18.338732] FS:  77fdb700() GS:88007ed8() 
knlGS:
[   18.344827] CS:  0010 DS:  ES:  CR0: 80050033
[   18.346395] CR2:  CR3: 7c39e000 CR4: 000406e0
[   18.348205] Call Trace:
[   18.348905]  __handle_sysrq+0x9e/0x160
[   18.349835]  write_sysrq_trigger+0x2b/0x30
[   18.350827]  proc_reg_write+0x38/0x70
[   18.351747]  __vfs_write+0x36/0x160
[   18.356573]  ? __fd_install+0x69/0x110
[   18.357516]  ? preempt_count_add+0x74/0xb0
[   18.358509]  ? _raw_spin_lock+0x13/0x30
[   18.359454]  ? set_close_on_exec+0x41/0x80
[   18.360468]  ? preempt_count_sub+0xa8/0x100
[   18.361476]  vfs_write+0xc0/0x190
[   18.362327]  SyS_write+0x64/0xe0
[   18.363162]  ? trace_hardirqs_off_thunk+0x1a/0x1c
[   18.364269]  do_syscall_64+0x76/0x140
[   18.368969]  entry_SYSCALL_64_after_hwframe+0x42/0xb7
[   18.370390] RIP: 0033:0x774b9620
[   18.371479] RSP: 002b:7fffe7a8 EFLAGS: 0246
[   18.371481] Code: ff 73 01 c3 48 8b 0d 68 98 2c 00 f7 d8 64 89 01 48 83 c8 
ff c3 66 0f 1f 44 00 00 83 3d bd f1 2c 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 
01 f0 ff ff 73 31 c3 48 83 ec 08 e8 ce 8f 01 00 48 89 04 
[   18.377743]  ORIG_RAX: 0001
[   18.381942] RAX: ffda RBX: 0002 RCX: 774b9620
[   18.383212] RDX: 0002 RSI: 00705408 RDI: 0001
[   18.384490] RBP: 00705408 R08: 000a R09: 77fdb700
[   18.385759] R10: 777826a0 R11: 0246 R12: 777842a0
[   18.387024] R13: 0002 R14: 0001 R15: 
[   18.388437] RIP: 0010:sysrq_handle_crash+0x17/0x20
[   18.389550] RSP: 0018:c9c23df0 EFLAGS: 00010246
[   18.389550] Code: eb d1 e8 fd ca b6 ff 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 
00 0f 1f 44 00 00 e8 f6 de bc ff c7 05 84 0d 1a 01 01 00 00 00 0f ae f8  04 
25 00 00 00 00 01 c3 0f 1f 44 00 00 e8 86 df c1 ff fb 66 
[   18.398707] CR2: 
[   18.399864] ---[ end trace e17dc9a4aa5cc4d9 ]---
[   18.401351] Kernel panic - not syncing: Fatal exception
[   18.401678] Kernel Offset: disabled
[   18.408342] ---[ end Kernel panic - not syncing: Fatal exception

32-bit, respectively:

[   20.992127] sysrq: SysRq : Trigger a crash
[   20.994364] BUG: unable to handle kernel NULL pointer dereference at   (null)
[   20.997892] IP: sysrq_handle_crash+0x1d/0x30
[   20.999807] *pde =  
[   21.000512] Oops: 0002 [#1] PREEMPT SMP
[   21.007170] Modules linked in:
[   21.008299] CPU: 4 PID: 2079 Comm: bash Not tainted 4.16.0-rc1+ #18
[   21.022652] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.10.2-1 04/01/2014
[   21.024480] EIP: sysrq_handle_crash+0x1d/0x30 SS:ESP: 0068:f3f21e8c
[   21.026929] Code: bf ff eb d6 e8 35 eb b9 ff 90 8d 74 26 00 0f 1f 44 00 00 
55 89 e5 e8 d3 dd bf ff c7 05 b4 ba c3 c1 01 00 00 00 0f ae f8 0f 1f 00  05 
00 00 00 00 01 5d c3 8d 76 00 8d bc 27 00 00 00 00 0f 1f 
[   21.037904] EAX:  EBX: 000a ECX:  EDX: c1505fe0
[   21.039740] ESI: 0063 EDI:  EBP: f3f21e8c ESP: f3f21e8c
[   21.041575]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 

Re: [PATCH 0/5] x86/dumpstack: Cleanups and user opcode bytes Code: section

[Borislav Petkov]

On Wed, Feb 21, 2018 at 10:15:53AM +0100, Ingo Molnar wrote:
> That looks really useful!

Ok, lemme run it by Linus too as he probably stares at this part of the
output a *lot* :-)

Combined patch at the end. I'll split it later.

@Linus: also, pls have a look at
https://lkml.kernel.org/r/20180219202826.19797-6...@alien8.de

I've added Code: section to user faults too because there might be
some usefulness in seeing the user opcode bytes when it faults. Some
arguments in the commit message there.

Anyway, here's a 64-bit splat. I'm basically dumping opcode bytes
everytime we dump RIP.

[   18.304872] sysrq: SysRq : Trigger a crash
[   18.306961] BUG: unable to handle kernel NULL pointer dereference at 
  (null)
[   18.310702] IP: sysrq_handle_crash+0x17/0x20
[   18.312830] PGD 7a972067 P4D 7a972067 PUD 7a351067 PMD 0 
[   18.316431] Oops: 0002 [#1] PREEMPT SMP
[   18.317219] Modules linked in:
[   18.317865] CPU: 6 PID: 3681 Comm: bash Not tainted 4.16.0-rc1+ #14
[   18.319237] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.10.2-1 04/01/2014
[   18.321162] RIP: 0010:sysrq_handle_crash+0x17/0x20
[   18.322273] RSP: 0018:c9c23df0 EFLAGS: 00010246
[   18.322274] Code: eb d1 e8 fd ca b6 ff 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 
00 0f 1f 44 00 00 e8 f6 de bc ff c7 05 84 0d 1a 01 01 00 00 00 0f ae f8  04 
25 00 00 00 00 01 c3 0f 1f 44 00 00 e8 86 df c1 ff fb 66 
[   18.331362] RAX:  RBX: 0063 RCX: 
[   18.332660] RDX:  RSI: 81103293 RDI: 0063
[   18.333931] RBP: 82271880 R08: 01a4 R09: 0004a6e8
[   18.335209] R10:  R11:  R12: 000a
[   18.336874] R13:  R14:  R15: 
[   18.338732] FS:  77fdb700() GS:88007ed8() 
knlGS:
[   18.344827] CS:  0010 DS:  ES:  CR0: 80050033
[   18.346395] CR2:  CR3: 7c39e000 CR4: 000406e0
[   18.348205] Call Trace:
[   18.348905]  __handle_sysrq+0x9e/0x160
[   18.349835]  write_sysrq_trigger+0x2b/0x30
[   18.350827]  proc_reg_write+0x38/0x70
[   18.351747]  __vfs_write+0x36/0x160
[   18.356573]  ? __fd_install+0x69/0x110
[   18.357516]  ? preempt_count_add+0x74/0xb0
[   18.358509]  ? _raw_spin_lock+0x13/0x30
[   18.359454]  ? set_close_on_exec+0x41/0x80
[   18.360468]  ? preempt_count_sub+0xa8/0x100
[   18.361476]  vfs_write+0xc0/0x190
[   18.362327]  SyS_write+0x64/0xe0
[   18.363162]  ? trace_hardirqs_off_thunk+0x1a/0x1c
[   18.364269]  do_syscall_64+0x76/0x140
[   18.368969]  entry_SYSCALL_64_after_hwframe+0x42/0xb7
[   18.370390] RIP: 0033:0x774b9620
[   18.371479] RSP: 002b:7fffe7a8 EFLAGS: 0246
[   18.371481] Code: ff 73 01 c3 48 8b 0d 68 98 2c 00 f7 d8 64 89 01 48 83 c8 
ff c3 66 0f 1f 44 00 00 83 3d bd f1 2c 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 
01 f0 ff ff 73 31 c3 48 83 ec 08 e8 ce 8f 01 00 48 89 04 
[   18.377743]  ORIG_RAX: 0001
[   18.381942] RAX: ffda RBX: 0002 RCX: 774b9620
[   18.383212] RDX: 0002 RSI: 00705408 RDI: 0001
[   18.384490] RBP: 00705408 R08: 000a R09: 77fdb700
[   18.385759] R10: 777826a0 R11: 0246 R12: 777842a0
[   18.387024] R13: 0002 R14: 0001 R15: 
[   18.388437] RIP: 0010:sysrq_handle_crash+0x17/0x20
[   18.389550] RSP: 0018:c9c23df0 EFLAGS: 00010246
[   18.389550] Code: eb d1 e8 fd ca b6 ff 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 
00 0f 1f 44 00 00 e8 f6 de bc ff c7 05 84 0d 1a 01 01 00 00 00 0f ae f8  04 
25 00 00 00 00 01 c3 0f 1f 44 00 00 e8 86 df c1 ff fb 66 
[   18.398707] CR2: 
[   18.399864] ---[ end trace e17dc9a4aa5cc4d9 ]---
[   18.401351] Kernel panic - not syncing: Fatal exception
[   18.401678] Kernel Offset: disabled
[   18.408342] ---[ end Kernel panic - not syncing: Fatal exception

32-bit, respectively:

[   20.992127] sysrq: SysRq : Trigger a crash
[   20.994364] BUG: unable to handle kernel NULL pointer dereference at   (null)
[   20.997892] IP: sysrq_handle_crash+0x1d/0x30
[   20.999807] *pde =  
[   21.000512] Oops: 0002 [#1] PREEMPT SMP
[   21.007170] Modules linked in:
[   21.008299] CPU: 4 PID: 2079 Comm: bash Not tainted 4.16.0-rc1+ #18
[   21.022652] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.10.2-1 04/01/2014
[   21.024480] EIP: sysrq_handle_crash+0x1d/0x30 SS:ESP: 0068:f3f21e8c
[   21.026929] Code: bf ff eb d6 e8 35 eb b9 ff 90 8d 74 26 00 0f 1f 44 00 00 
55 89 e5 e8 d3 dd bf ff c7 05 b4 ba c3 c1 01 00 00 00 0f ae f8 0f 1f 00  05 
00 00 00 00 01 5d c3 8d 76 00 8d bc 27 00 00 00 00 0f 1f 
[   21.037904] EAX:  EBX: 000a ECX:  EDX: c1505fe0
[   21.039740] ESI: 0063 EDI:  EBP: f3f21e8c ESP: f3f21e8c
[   21.041575]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 

Re: [PATCH 0/5] x86/dumpstack: Cleanups and user opcode bytes Code: section

[Ingo Molnar]

* Borislav Petkov  wrote:

> On Tue, Feb 20, 2018 at 01:29:56PM -0600, Josh Poimboeuf wrote:
> > > Maybe this series already has this side-effect, but I'd really love to
> > > see oopses show the code bytes for each kernel entry, not just the
> > > innermode one.  We already dump full regs including RIP -- adding
> > > Code: should be easy and would be very helpful.
> > 
> > Just to clarify, I think you want to show the Code: around regs->ip
> > every time we show the registers?
> 
> It is an easy change to always dump Code: section when we dump RIP:.
> I.e., something like this:
> 
> [   33.192733] BUG: unable to handle kernel NULL pointer dereference at   
> (null)
> [   33.196510] IP: sysrq_handle_crash+0x17/0x20
> [   33.196691] PGD 78b12067 P4D 78b12067 PUD 78b7f067 PMD 0 
> [   33.196691] Oops: 0002 [#1] PREEMPT SMP
> [   33.196691] Modules linked in:
> [   33.196691] CPU: 6 PID: 3686 Comm: bash Not tainted 4.16.0-rc1+ #5
> [   33.196691] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> 1.10.2-1 04/01/2014
> [   33.196691] RIP: 0010:sysrq_handle_crash+0x17/0x20
> [   33.196691] RSP: 0018:c954bdf0 EFLAGS: 00010246
> [   33.196691] Code: eb d1 e8 5d 17 b7 ff 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 
> 00 0f 1f 44 00 00 e8 c6 24 bd ff c7 05 24 a2 19 01 01 00 00 00 0f ae f8  
> 04 25 00 00 00 00 01 c3 0f 1f 44 00 00 e8 86 21 c2 ff fb e9 
> [   33.196691] RAX:  RBX: 0063 RCX: 
> 
> [   33.196691] RDX:  RSI: 8110145a RDI: 
> 0063
> [   33.196691] RBP: 82271400 R08: 0183 R09: 
> 0002e771
> [   33.196691] R10:  R11:  R12: 
> 000a
> [   33.196691] R13:  R14:  R15: 
> 
> [   33.196691] FS:  77fdb700() GS:88007ed8() 
> knlGS:
> [   33.196691] CS:  0010 DS:  ES:  CR0: 80050033
> [   33.196691] CR2:  CR3: 7aa9e000 CR4: 
> 000406e0
> [   33.196691] Call Trace:
> [   33.196691]  __handle_sysrq+0x9e/0x160
> [   33.196691]  write_sysrq_trigger+0x2b/0x30
> [   33.196691]  proc_reg_write+0x38/0x70
> [   33.196691]  __vfs_write+0x36/0x160
> [   33.196691]  ? __fd_install+0x69/0x110
> [   33.196691]  ? preempt_count_add+0x74/0xb0
> [   33.196691]  ? _raw_spin_lock+0x13/0x30
> [   33.196691]  ? set_close_on_exec+0x41/0x80
> [   33.196691]  ? preempt_count_sub+0xa8/0x100
> [   33.196691]  vfs_write+0xc0/0x190
> [   33.196691]  SyS_write+0x64/0xe0
> [   33.196691]  ? trace_hardirqs_off_thunk+0x1a/0x1c
> [   33.196691]  do_syscall_64+0x70/0x130
> [   33.196691]  entry_SYSCALL_64_after_hwframe+0x42/0xb7
> [   33.196691] RIP: 0033:0x774b9620
> [   33.196691] RSP: 002b:7fffe7a8 EFLAGS: 0246
> [   33.196691] Code: ff 73 01 c3 48 8b 0d 68 98 2c 00 f7 d8 64 89 01 48 83 c8 
> ff c3 66 0f 1f 44 00 00 83 3d bd f1 2c 00 00 75 10 b8 01 00 00 00 0f 05 <48> 
> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 ce 8f 01 00 48 89 04 
> [   33.196691]  ORIG_RAX: 0001
> [   33.196691] RAX: ffda RBX: 0002 RCX: 
> 774b9620
> [   33.196691] RDX: 0002 RSI: 00705408 RDI: 
> 0001
> [   33.196691] RBP: 00705408 R08: 000a R09: 
> 77fdb700
> [   33.196691] R10: 777826a0 R11: 0246 R12: 
> 777842a0
> [   33.196691] R13: 0002 R14: 0001 R15: 
> 
> [   33.196691] Code: eb d1 e8 5d 17 b7 ff 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 
> 00 0f 1f 44 00 00 e8 c6 24 bd ff c7 05 24 a2 19 01 01 00 00 00 0f ae f8  
> 04 25 00 00 00 00 01 c3 0f 1f 44 00 00 e8 86 21 c2 ff fb e9 
> [   33.196691] RIP: sysrq_handle_crash+0x17/0x20 RSP: c954bdf0
> [   33.196691] CR2: 
> [   33.301033] ---[ end trace b97275941de8c6f4 ]---
> [   33.302600] Kernel panic - not syncing: Fatal exception
> [   33.304529] Kernel Offset: disabled
> [   33.304973] ---[ end Kernel panic - not syncing: Fatal exception

That looks really useful!

Thanks,

Ingo

Re: [PATCH 0/5] x86/dumpstack: Cleanups and user opcode bytes Code: section

[Ingo Molnar]

* Borislav Petkov  wrote:

> On Tue, Feb 20, 2018 at 01:29:56PM -0600, Josh Poimboeuf wrote:
> > > Maybe this series already has this side-effect, but I'd really love to
> > > see oopses show the code bytes for each kernel entry, not just the
> > > innermode one.  We already dump full regs including RIP -- adding
> > > Code: should be easy and would be very helpful.
> > 
> > Just to clarify, I think you want to show the Code: around regs->ip
> > every time we show the registers?
> 
> It is an easy change to always dump Code: section when we dump RIP:.
> I.e., something like this:
> 
> [   33.192733] BUG: unable to handle kernel NULL pointer dereference at   
> (null)
> [   33.196510] IP: sysrq_handle_crash+0x17/0x20
> [   33.196691] PGD 78b12067 P4D 78b12067 PUD 78b7f067 PMD 0 
> [   33.196691] Oops: 0002 [#1] PREEMPT SMP
> [   33.196691] Modules linked in:
> [   33.196691] CPU: 6 PID: 3686 Comm: bash Not tainted 4.16.0-rc1+ #5
> [   33.196691] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> 1.10.2-1 04/01/2014
> [   33.196691] RIP: 0010:sysrq_handle_crash+0x17/0x20
> [   33.196691] RSP: 0018:c954bdf0 EFLAGS: 00010246
> [   33.196691] Code: eb d1 e8 5d 17 b7 ff 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 
> 00 0f 1f 44 00 00 e8 c6 24 bd ff c7 05 24 a2 19 01 01 00 00 00 0f ae f8  
> 04 25 00 00 00 00 01 c3 0f 1f 44 00 00 e8 86 21 c2 ff fb e9 
> [   33.196691] RAX:  RBX: 0063 RCX: 
> 
> [   33.196691] RDX:  RSI: 8110145a RDI: 
> 0063
> [   33.196691] RBP: 82271400 R08: 0183 R09: 
> 0002e771
> [   33.196691] R10:  R11:  R12: 
> 000a
> [   33.196691] R13:  R14:  R15: 
> 
> [   33.196691] FS:  77fdb700() GS:88007ed8() 
> knlGS:
> [   33.196691] CS:  0010 DS:  ES:  CR0: 80050033
> [   33.196691] CR2:  CR3: 7aa9e000 CR4: 
> 000406e0
> [   33.196691] Call Trace:
> [   33.196691]  __handle_sysrq+0x9e/0x160
> [   33.196691]  write_sysrq_trigger+0x2b/0x30
> [   33.196691]  proc_reg_write+0x38/0x70
> [   33.196691]  __vfs_write+0x36/0x160
> [   33.196691]  ? __fd_install+0x69/0x110
> [   33.196691]  ? preempt_count_add+0x74/0xb0
> [   33.196691]  ? _raw_spin_lock+0x13/0x30
> [   33.196691]  ? set_close_on_exec+0x41/0x80
> [   33.196691]  ? preempt_count_sub+0xa8/0x100
> [   33.196691]  vfs_write+0xc0/0x190
> [   33.196691]  SyS_write+0x64/0xe0
> [   33.196691]  ? trace_hardirqs_off_thunk+0x1a/0x1c
> [   33.196691]  do_syscall_64+0x70/0x130
> [   33.196691]  entry_SYSCALL_64_after_hwframe+0x42/0xb7
> [   33.196691] RIP: 0033:0x774b9620
> [   33.196691] RSP: 002b:7fffe7a8 EFLAGS: 0246
> [   33.196691] Code: ff 73 01 c3 48 8b 0d 68 98 2c 00 f7 d8 64 89 01 48 83 c8 
> ff c3 66 0f 1f 44 00 00 83 3d bd f1 2c 00 00 75 10 b8 01 00 00 00 0f 05 <48> 
> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 ce 8f 01 00 48 89 04 
> [   33.196691]  ORIG_RAX: 0001
> [   33.196691] RAX: ffda RBX: 0002 RCX: 
> 774b9620
> [   33.196691] RDX: 0002 RSI: 00705408 RDI: 
> 0001
> [   33.196691] RBP: 00705408 R08: 000a R09: 
> 77fdb700
> [   33.196691] R10: 777826a0 R11: 0246 R12: 
> 777842a0
> [   33.196691] R13: 0002 R14: 0001 R15: 
> 
> [   33.196691] Code: eb d1 e8 5d 17 b7 ff 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 
> 00 0f 1f 44 00 00 e8 c6 24 bd ff c7 05 24 a2 19 01 01 00 00 00 0f ae f8  
> 04 25 00 00 00 00 01 c3 0f 1f 44 00 00 e8 86 21 c2 ff fb e9 
> [   33.196691] RIP: sysrq_handle_crash+0x17/0x20 RSP: c954bdf0
> [   33.196691] CR2: 
> [   33.301033] ---[ end trace b97275941de8c6f4 ]---
> [   33.302600] Kernel panic - not syncing: Fatal exception
> [   33.304529] Kernel Offset: disabled
> [   33.304973] ---[ end Kernel panic - not syncing: Fatal exception

That looks really useful!

Thanks,

Ingo

Re: [PATCH 0/5] x86/dumpstack: Cleanups and user opcode bytes Code: section

[Borislav Petkov]

On Tue, Feb 20, 2018 at 01:29:56PM -0600, Josh Poimboeuf wrote:
> > Maybe this series already has this side-effect, but I'd really love to
> > see oopses show the code bytes for each kernel entry, not just the
> > innermode one.  We already dump full regs including RIP -- adding
> > Code: should be easy and would be very helpful.
> 
> Just to clarify, I think you want to show the Code: around regs->ip
> every time we show the registers?

It is an easy change to always dump Code: section when we dump RIP:.
I.e., something like this:

[   33.192733] BUG: unable to handle kernel NULL pointer dereference at 
  (null)
[   33.196510] IP: sysrq_handle_crash+0x17/0x20
[   33.196691] PGD 78b12067 P4D 78b12067 PUD 78b7f067 PMD 0 
[   33.196691] Oops: 0002 [#1] PREEMPT SMP
[   33.196691] Modules linked in:
[   33.196691] CPU: 6 PID: 3686 Comm: bash Not tainted 4.16.0-rc1+ #5
[   33.196691] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.10.2-1 04/01/2014
[   33.196691] RIP: 0010:sysrq_handle_crash+0x17/0x20
[   33.196691] RSP: 0018:c954bdf0 EFLAGS: 00010246
[   33.196691] Code: eb d1 e8 5d 17 b7 ff 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 
00 0f 1f 44 00 00 e8 c6 24 bd ff c7 05 24 a2 19 01 01 00 00 00 0f ae f8  04 
25 00 00 00 00 01 c3 0f 1f 44 00 00 e8 86 21 c2 ff fb e9 
[   33.196691] RAX:  RBX: 0063 RCX: 
[   33.196691] RDX:  RSI: 8110145a RDI: 0063
[   33.196691] RBP: 82271400 R08: 0183 R09: 0002e771
[   33.196691] R10:  R11:  R12: 000a
[   33.196691] R13:  R14:  R15: 
[   33.196691] FS:  77fdb700() GS:88007ed8() 
knlGS:
[   33.196691] CS:  0010 DS:  ES:  CR0: 80050033
[   33.196691] CR2:  CR3: 7aa9e000 CR4: 000406e0
[   33.196691] Call Trace:
[   33.196691]  __handle_sysrq+0x9e/0x160
[   33.196691]  write_sysrq_trigger+0x2b/0x30
[   33.196691]  proc_reg_write+0x38/0x70
[   33.196691]  __vfs_write+0x36/0x160
[   33.196691]  ? __fd_install+0x69/0x110
[   33.196691]  ? preempt_count_add+0x74/0xb0
[   33.196691]  ? _raw_spin_lock+0x13/0x30
[   33.196691]  ? set_close_on_exec+0x41/0x80
[   33.196691]  ? preempt_count_sub+0xa8/0x100
[   33.196691]  vfs_write+0xc0/0x190
[   33.196691]  SyS_write+0x64/0xe0
[   33.196691]  ? trace_hardirqs_off_thunk+0x1a/0x1c
[   33.196691]  do_syscall_64+0x70/0x130
[   33.196691]  entry_SYSCALL_64_after_hwframe+0x42/0xb7
[   33.196691] RIP: 0033:0x774b9620
[   33.196691] RSP: 002b:7fffe7a8 EFLAGS: 0246
[   33.196691] Code: ff 73 01 c3 48 8b 0d 68 98 2c 00 f7 d8 64 89 01 48 83 c8 
ff c3 66 0f 1f 44 00 00 83 3d bd f1 2c 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 
01 f0 ff ff 73 31 c3 48 83 ec 08 e8 ce 8f 01 00 48 89 04 
[   33.196691]  ORIG_RAX: 0001
[   33.196691] RAX: ffda RBX: 0002 RCX: 774b9620
[   33.196691] RDX: 0002 RSI: 00705408 RDI: 0001
[   33.196691] RBP: 00705408 R08: 000a R09: 77fdb700
[   33.196691] R10: 777826a0 R11: 0246 R12: 777842a0
[   33.196691] R13: 0002 R14: 0001 R15: 
[   33.196691] Code: eb d1 e8 5d 17 b7 ff 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 
00 0f 1f 44 00 00 e8 c6 24 bd ff c7 05 24 a2 19 01 01 00 00 00 0f ae f8  04 
25 00 00 00 00 01 c3 0f 1f 44 00 00 e8 86 21 c2 ff fb e9 
[   33.196691] RIP: sysrq_handle_crash+0x17/0x20 RSP: c954bdf0
[   33.196691] CR2: 
[   33.301033] ---[ end trace b97275941de8c6f4 ]---
[   33.302600] Kernel panic - not syncing: Fatal exception
[   33.304529] Kernel Offset: disabled
[   33.304973] ---[ end Kernel panic - not syncing: Fatal exception

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [PATCH 0/5] x86/dumpstack: Cleanups and user opcode bytes Code: section

[Borislav Petkov]

On Tue, Feb 20, 2018 at 01:29:56PM -0600, Josh Poimboeuf wrote:
> > Maybe this series already has this side-effect, but I'd really love to
> > see oopses show the code bytes for each kernel entry, not just the
> > innermode one.  We already dump full regs including RIP -- adding
> > Code: should be easy and would be very helpful.
> 
> Just to clarify, I think you want to show the Code: around regs->ip
> every time we show the registers?

It is an easy change to always dump Code: section when we dump RIP:.
I.e., something like this:

[   33.192733] BUG: unable to handle kernel NULL pointer dereference at 
  (null)
[   33.196510] IP: sysrq_handle_crash+0x17/0x20
[   33.196691] PGD 78b12067 P4D 78b12067 PUD 78b7f067 PMD 0 
[   33.196691] Oops: 0002 [#1] PREEMPT SMP
[   33.196691] Modules linked in:
[   33.196691] CPU: 6 PID: 3686 Comm: bash Not tainted 4.16.0-rc1+ #5
[   33.196691] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.10.2-1 04/01/2014
[   33.196691] RIP: 0010:sysrq_handle_crash+0x17/0x20
[   33.196691] RSP: 0018:c954bdf0 EFLAGS: 00010246
[   33.196691] Code: eb d1 e8 5d 17 b7 ff 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 
00 0f 1f 44 00 00 e8 c6 24 bd ff c7 05 24 a2 19 01 01 00 00 00 0f ae f8  04 
25 00 00 00 00 01 c3 0f 1f 44 00 00 e8 86 21 c2 ff fb e9 
[   33.196691] RAX:  RBX: 0063 RCX: 
[   33.196691] RDX:  RSI: 8110145a RDI: 0063
[   33.196691] RBP: 82271400 R08: 0183 R09: 0002e771
[   33.196691] R10:  R11:  R12: 000a
[   33.196691] R13:  R14:  R15: 
[   33.196691] FS:  77fdb700() GS:88007ed8() 
knlGS:
[   33.196691] CS:  0010 DS:  ES:  CR0: 80050033
[   33.196691] CR2:  CR3: 7aa9e000 CR4: 000406e0
[   33.196691] Call Trace:
[   33.196691]  __handle_sysrq+0x9e/0x160
[   33.196691]  write_sysrq_trigger+0x2b/0x30
[   33.196691]  proc_reg_write+0x38/0x70
[   33.196691]  __vfs_write+0x36/0x160
[   33.196691]  ? __fd_install+0x69/0x110
[   33.196691]  ? preempt_count_add+0x74/0xb0
[   33.196691]  ? _raw_spin_lock+0x13/0x30
[   33.196691]  ? set_close_on_exec+0x41/0x80
[   33.196691]  ? preempt_count_sub+0xa8/0x100
[   33.196691]  vfs_write+0xc0/0x190
[   33.196691]  SyS_write+0x64/0xe0
[   33.196691]  ? trace_hardirqs_off_thunk+0x1a/0x1c
[   33.196691]  do_syscall_64+0x70/0x130
[   33.196691]  entry_SYSCALL_64_after_hwframe+0x42/0xb7
[   33.196691] RIP: 0033:0x774b9620
[   33.196691] RSP: 002b:7fffe7a8 EFLAGS: 0246
[   33.196691] Code: ff 73 01 c3 48 8b 0d 68 98 2c 00 f7 d8 64 89 01 48 83 c8 
ff c3 66 0f 1f 44 00 00 83 3d bd f1 2c 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 
01 f0 ff ff 73 31 c3 48 83 ec 08 e8 ce 8f 01 00 48 89 04 
[   33.196691]  ORIG_RAX: 0001
[   33.196691] RAX: ffda RBX: 0002 RCX: 774b9620
[   33.196691] RDX: 0002 RSI: 00705408 RDI: 0001
[   33.196691] RBP: 00705408 R08: 000a R09: 77fdb700
[   33.196691] R10: 777826a0 R11: 0246 R12: 777842a0
[   33.196691] R13: 0002 R14: 0001 R15: 
[   33.196691] Code: eb d1 e8 5d 17 b7 ff 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 
00 0f 1f 44 00 00 e8 c6 24 bd ff c7 05 24 a2 19 01 01 00 00 00 0f ae f8  04 
25 00 00 00 00 01 c3 0f 1f 44 00 00 e8 86 21 c2 ff fb e9 
[   33.196691] RIP: sysrq_handle_crash+0x17/0x20 RSP: c954bdf0
[   33.196691] CR2: 
[   33.301033] ---[ end trace b97275941de8c6f4 ]---
[   33.302600] Kernel panic - not syncing: Fatal exception
[   33.304529] Kernel Offset: disabled
[   33.304973] ---[ end Kernel panic - not syncing: Fatal exception

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [PATCH 0/5] x86/dumpstack: Cleanups and user opcode bytes Code: section

[Josh Poimboeuf]

On Tue, Feb 20, 2018 at 07:14:00PM +, Andy Lutomirski wrote:
> On Mon, Feb 19, 2018 at 8:28 PM, Borislav Petkov  wrote:
> > From: Borislav Petkov 
> >
> > Hi,
> >
> > so I've been thinking about doing this for a while now: be able to dump
> > the opcode bytes around the user rIP just like we do for kernel faults.
> >
> > Why?
> >
> > See patch 5's commit message. That's why I've marked it RFC.
> >
> > The rest is cleanups: we're copying the opcodes byte-by-byte and that's
> > just wasteful.
> 
> Maybe this series already has this side-effect, but I'd really love to
> see oopses show the code bytes for each kernel entry, not just the
> innermode one.  We already dump full regs including RIP -- adding
> Code: should be easy and would be very helpful.

Just to clarify, I think you want to show the Code: around regs->ip
every time we show the registers?

-- 
Josh

Re: [PATCH 0/5] x86/dumpstack: Cleanups and user opcode bytes Code: section

[Josh Poimboeuf]

On Tue, Feb 20, 2018 at 07:14:00PM +, Andy Lutomirski wrote:
> On Mon, Feb 19, 2018 at 8:28 PM, Borislav Petkov  wrote:
> > From: Borislav Petkov 
> >
> > Hi,
> >
> > so I've been thinking about doing this for a while now: be able to dump
> > the opcode bytes around the user rIP just like we do for kernel faults.
> >
> > Why?
> >
> > See patch 5's commit message. That's why I've marked it RFC.
> >
> > The rest is cleanups: we're copying the opcodes byte-by-byte and that's
> > just wasteful.
> 
> Maybe this series already has this side-effect, but I'd really love to
> see oopses show the code bytes for each kernel entry, not just the
> innermode one.  We already dump full regs including RIP -- adding
> Code: should be easy and would be very helpful.

Just to clarify, I think you want to show the Code: around regs->ip
every time we show the registers?

-- 
Josh

Re: [PATCH 0/5] x86/dumpstack: Cleanups and user opcode bytes Code: section

[Andy Lutomirski]

On Mon, Feb 19, 2018 at 8:28 PM, Borislav Petkov  wrote:
> From: Borislav Petkov 
>
> Hi,
>
> so I've been thinking about doing this for a while now: be able to dump
> the opcode bytes around the user rIP just like we do for kernel faults.
>
> Why?
>
> See patch 5's commit message. That's why I've marked it RFC.
>
> The rest is cleanups: we're copying the opcodes byte-by-byte and that's
> just wasteful.

Maybe this series already has this side-effect, but I'd really love to
see oopses show the code bytes for each kernel entry, not just the
innermode one.  We already dump full regs including RIP -- adding
Code: should be easy and would be very helpful.

Re: [PATCH 0/5] x86/dumpstack: Cleanups and user opcode bytes Code: section

[Andy Lutomirski]

On Mon, Feb 19, 2018 at 8:28 PM, Borislav Petkov  wrote:
> From: Borislav Petkov 
>
> Hi,
>
> so I've been thinking about doing this for a while now: be able to dump
> the opcode bytes around the user rIP just like we do for kernel faults.
>
> Why?
>
> See patch 5's commit message. That's why I've marked it RFC.
>
> The rest is cleanups: we're copying the opcodes byte-by-byte and that's
> just wasteful.

Maybe this series already has this side-effect, but I'd really love to
see oopses show the code bytes for each kernel entry, not just the
innermode one.  We already dump full regs including RIP -- adding
Code: should be easy and would be very helpful.