The patch titled
Subject: kernel/printk/printk.c: fix faulty logic in the case of recursive
printk
has been added to the -mm tree. Its filename is
fix-faulty-logic-in-the-case-of-recursive-printk.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/fix-faulty-logic-in-the-case-of-recursive-printk.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/fix-faulty-logic-in-the-case-of-recursive-printk.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Patrick Palka <[email protected]>
Subject: kernel/printk/printk.c: fix faulty logic in the case of recursive
printk
We shouldn't set text_len in the code path that detects printk recursion
because text_len corresponds to the length of the string inside textbuf.
A few lines down from the line
text_len = strlen(recursion_msg);
is the line
text_len += vscnprintf(text + text_len, ...);
So if printk detects recursion, it sets text_len to 29 (the length of
recursion_msg) and logs an error. Then the message supplied by the caller
of printk is stored inside textbuf but offset by 29 bytes. This means
that the output of the recursive call to printk will contain 29 bytes of
garbage in front of it.
This defect is caused by commit 458df9fd ("printk: remove separate
printk_sched buffers and use printk buf instead") which turned the line
text_len = vscnprintf(text, ...);
into
text_len += vscnprintf(text + text_len, ...);
To fix this, this patch avoids setting text_len when logging the printk
recursion error. This patch also marks unlikely() the branch leading up
to this code.
Fixes: 458df9fd4815b478 ("printk: remove separate printk_sched buffers and use
printk buf instead")
Signed-off-by: Patrick Palka <[email protected]>
Cc: Petr Mladek <[email protected]>
Reviewed-by: Jan Kara <[email protected]>
Cc: Steven Rostedt <[email protected]>
Cc: <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
---
kernel/printk/printk.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff -puN
kernel/printk/printk.c~fix-faulty-logic-in-the-case-of-recursive-printk
kernel/printk/printk.c
--- a/kernel/printk/printk.c~fix-faulty-logic-in-the-case-of-recursive-printk
+++ a/kernel/printk/printk.c
@@ -1665,15 +1665,15 @@ asmlinkage int vprintk_emit(int facility
raw_spin_lock(&logbuf_lock);
logbuf_cpu = this_cpu;
- if (recursion_bug) {
+ if (unlikely(recursion_bug)) {
static const char recursion_msg[] =
"BUG: recent printk recursion!";
recursion_bug = 0;
- text_len = strlen(recursion_msg);
/* emit KERN_CRIT message */
printed_len += log_store(0, 2, LOG_PREFIX|LOG_NEWLINE, 0,
- NULL, 0, recursion_msg, text_len);
+ NULL, 0, recursion_msg,
+ strlen(recursion_msg));
}
/*
_
Patches currently in -mm which might be from [email protected] are
fix-faulty-logic-in-the-case-of-recursive-printk.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
