From: Dmitry Vyukov <[email protected]>
KERN_CONT leads to split lines in kernel output
and complicates useful changes to printk like
printing context before each line.
Only acceptable use of continuations is basically
boot-time testing.
Get rid of it.
Signed-off-by: Dmitry Vyukov <[email protected]>
---
arch/x86/mm/fault.c | 10 +++-------
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index 9a84a0d08727..2a2def636545 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -671,13 +671,9 @@ show_fault_oops(struct pt_regs *regs, unsigned long error_code,
printk(smep_warning, from_kuid(&init_user_ns, current_uid()));
}
- printk(KERN_ALERT "BUG: unable to handle kernel ");
- if (address < PAGE_SIZE)
- printk(KERN_CONT "NULL pointer dereference");
- else
- printk(KERN_CONT "paging request");
-
- printk(KERN_CONT " at %px\n", (void *) address);
+ printk(KERN_ALERT "BUG: unable to handle kernel %s at %px\n",
+ (address < PAGE_SIZE ? "NULL pointer dereference" :
+ "paging request"), (void *) address);
dump_pagetable(address);
}
--
2.18.0.rc1.244.gcf134e6275-goog
On Wed, Jun 20, 2018 at 3:55 PM, Dmitry Vyukov <[email protected]> wrote:
> From: Dmitry Vyukov <[email protected]>
>
> KERN_CONT leads to split lines in kernel output
> and complicates useful changes to printk like
> printing context before each line.
>
> Only acceptable use of continuations is basically
> boot-time testing.
>
> Get rid of it.
> + printk(KERN_ALERT "BUG: unable to handle kernel %s at %px\n",
> + (address < PAGE_SIZE ? "NULL pointer dereference" :
> + "paging request"), (void *) address);
Perhaps pr_alert() ?
Btw, parens are redundant for the first argument.
P.S. And personally I would rather do
if (address < PAGE_SIZE)
pr_alert(...NULL pointer dereference...);
else
pr_alert(...paging request...);
--
With Best Regards,
Andy Shevchenko
On Thu, Jun 21, 2018 at 3:06 AM, Andy Shevchenko
<[email protected]> wrote:
> On Wed, Jun 20, 2018 at 3:55 PM, Dmitry Vyukov <[email protected]> wrote:
>> From: Dmitry Vyukov <[email protected]>
>>
>> KERN_CONT leads to split lines in kernel output
>> and complicates useful changes to printk like
>> printing context before each line.
>>
>> Only acceptable use of continuations is basically
>> boot-time testing.
>>
>> Get rid of it.
>
>> + printk(KERN_ALERT "BUG: unable to handle kernel %s at %px\n",
>> + (address < PAGE_SIZE ? "NULL pointer dereference" :
>> + "paging request"), (void *) address);
>
> Perhaps pr_alert() ?
It's the same, right? Make sense.
> Btw, parens are redundant for the first argument.
>
> P.S. And personally I would rather do
> if (address < PAGE_SIZE)
> pr_alert(...NULL pointer dereference...);
> else
> pr_alert(...paging request...);
It's kinda shorter this way. Any other opinions?
pr_alert("BUG: unable to handle kernel %s at %px\n",
address < PAGE_SIZE ? "NULL pointer dereference" :
"paging request", (void *) address);
vs:
if (address < PAGE_SIZE)
pr_alert("BUG: unable to handle kernel NULL pointer
dereference at %px\n",
(void *) address);
else
pr_alert("BUG: unable to handle kernel paging request at %px\n",
(void *) address);
Or, should we just do:
pr_alert("BUG: unable to handle kernel paging request at %px\n",
(void *) address);
and not try to be too smart here? In the end, that can be a NULL deref
with 5K offset, right?
On (06/21/18 09:59), Dmitry Vyukov wrote:
> >
> >> + printk(KERN_ALERT "BUG: unable to handle kernel %s at %px\n",
> >> + (address < PAGE_SIZE ? "NULL pointer dereference" :
> >> + "paging request"), (void *) address);
> >
> > Perhaps pr_alert() ?
>
> It's the same, right? Make sense.
Right.
In printk(KERN_<LEVEL> ...) people tend to forget KERN_<LEVEL> sometimes,
so, I think, in general we want to see more pr_foo() and less printk().
-ss
On Thu, Jun 21, 2018 at 10:17 AM, Sergey Senozhatsky
<[email protected]> wrote:
> On (06/21/18 09:59), Dmitry Vyukov wrote:
>> >
>> >> + printk(KERN_ALERT "BUG: unable to handle kernel %s at %px\n",
>> >> + (address < PAGE_SIZE ? "NULL pointer dereference" :
>> >> + "paging request"), (void *) address);
>> >
>> > Perhaps pr_alert() ?
>>
>> It's the same, right? Make sense.
>
> Right.
>
> In printk(KERN_<LEVEL> ...) people tend to forget KERN_<LEVEL> sometimes,
> so, I think, in general we want to see more pr_foo() and less printk().
Mailed v2 with pr_alert().
Since nobody else commented on single pr_alert() with ternary operator
vs if + 2 pr_alert()'s, I left it intact for now.