From: Roland Hieber <r.hieber@pengutronix.de>
To: barebox@lists.infradead.org
Subject: Re: [PATCH] printk: make line continuation not result in stray emergency errors
Date: Tue, 20 Nov 2018 22:06:39 +0100 [thread overview]
Message-ID: <20181120210639.v4dnho3arhj5jxoh@pengutronix.de> (raw)
In-Reply-To: <20181120205044.30768-1-r.hieber@pengutronix.de>
On Tue, Nov 20, 2018 at 09:50:44PM +0100, Roland Hieber wrote:
> The levels of pr_emerg() and pr_cont() are both set to 0. When pr_cont()
> is used to continue a previous line, and colored console output is
> enabled, this can result in garbled log messages being printed, e.g.:
>
> ERROR: HABv4: -------- HAB warning Event 0 --------
> ERROR: HABv4: event data:
> ERROR: HABv4: dbEMERG: 00EMERG: 24EMERG: 42EMERG: 69EMERG: 30EMERG: e1EMERG: 1d
> ERROR: HABv4: 00EMERG: 04EMERG: 00EMERG: 02EMERG: 40EMERG: 00EMERG: 36EMERG: 06
> ERROR: HABv4: 55EMERG: 55EMERG: 00EMERG: 03EMERG: 00EMERG: 00EMERG: 00EMERG: 00
> ERROR: HABv4: 00EMERG: 00EMERG: 00EMERG: 00EMERG: 00EMERG: 00EMERG: 00EMERG: 00
> ERROR: HABv4: 00EMERG: 00EMERG: 00EMERG: 01EMERG:
> ERROR: HABv4: Status: Operation completed with warning (0x69)
>
> Note the additional "EMERG: " in front of each continuation, which is
> inserted by pr_cont(buf) being expanded to pr_printk(0, buf). These
> additional strings show up in deep red on the console (which is not
> supported in Git commit messages…). One might argue that this is the
> same color as the "ERROR: " prefix, but when pr_cont() is used with
> pr_notice() and pr_warning(), which are printed in blue and yellow
> respectively, at least then the change in color would lead to additional
> confusion.
>
> The log level argument to pr_printk is defined as int, so we can solve
> this by defining the level for pr_cont() to -1, which is not used for
> any loglevel:
>
> ERROR: HABv4: -------- HAB warning Event 0 --------
> ERROR: HABv4: event data:
> ERROR: HABv4: db 00 24 42 69 30 e1 1d
> ERROR: HABv4: 00 04 00 02 40 00 36 06
> ERROR: HABv4: 55 55 00 03 00 00 00 00
> ERROR: HABv4: 00 00 00 00 00 00 00 00
> ERROR: HABv4: 00 00 00 01
> ERROR: HABv4: Status: Operation completed with warning (0x69)
>
> Fixes: 0fcefdd9369050f35a88b41dcd42cc5a3c6c6b33 ("printk: Add pr_cont")
> Fixes: ea0e077ed65a003e4d7a1e023aee38cbe2d14898 ("printk: Fix pr_cont")
> Signed-off-by: Roland Hieber <r.hieber@pengutronix.de>
> ---
> include/printk.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/printk.h b/include/printk.h
> index 4384fb85ea..858e800543 100644
> --- a/include/printk.h
> +++ b/include/printk.h
> @@ -84,21 +84,21 @@ static inline int pr_print(int level, const char *format, ...)
> #define pr_emerg(fmt, arg...) __pr_printk(0, pr_fmt(fmt), ##arg)
> #define pr_alert(fmt, arg...) __pr_printk(1, pr_fmt(fmt), ##arg)
> #define pr_crit(fmt, arg...) __pr_printk(2, pr_fmt(fmt), ##arg)
> #define pr_err(fmt, arg...) __pr_printk(3, pr_fmt(fmt), ##arg)
> #define pr_warning(fmt, arg...) __pr_printk(4, pr_fmt(fmt), ##arg)
> #define pr_notice(fmt, arg...) __pr_printk(5, pr_fmt(fmt), ##arg)
> #define pr_info(fmt, arg...) __pr_printk(6, pr_fmt(fmt), ##arg)
> #define pr_debug(fmt, arg...) __pr_printk(7, pr_fmt(fmt), ##arg)
> #define debug(fmt, arg...) __pr_printk(7, pr_fmt(fmt), ##arg)
> #define pr_vdebug(fmt, arg...) __pr_printk(8, pr_fmt(fmt), ##arg)
> -#define pr_cont(fmt, arg...) __pr_printk(0, fmt, ##arg)
> +#define pr_cont(fmt, arg...) __pr_printk(-1, fmt, ##arg)
Hmmm. There is a different ugly detail here: pr_cont()s are always
printed regardless of the current loglevel, also with the old
implementation. I think we could remember the last used loglevel in
pr_debug(), pr_err(), pr_info() etc. code paths and let pr_printk()
decide on that basis if pr_cont() should be printed or not, i.e. from
which loglevel the current pr_cont() is a continuation.
But for now, this is out of scope of this patch. :)
- Roland
>
> #define printk_once(fmt, ...) \
> ({ \
> static bool __print_once ; \
> \
> if (!__print_once) { \
> __print_once = true; \
> printk(fmt, ##__VA_ARGS__); \
> } \
> })
> --
> 2.19.1
>
>
> _______________________________________________
> barebox mailing list
> barebox@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/barebox
--
Roland Hieber | r.hieber@pengutronix.de |
Pengutronix e.K. | https://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim | Phone: +49-5121-206917-5086 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next prev parent reply other threads:[~2018-11-20 21:08 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-20 20:50 Roland Hieber
2018-11-20 21:06 ` Roland Hieber [this message]
2018-11-21 8:43 ` Sascha Hauer
2018-11-21 8:51 ` Sascha Hauer
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=20181120210639.v4dnho3arhj5jxoh@pengutronix.de \
--to=r.hieber@pengutronix.de \
--cc=barebox@lists.infradead.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