[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190114080522.GA433@jagdpanzerIV>
Date: Mon, 14 Jan 2019 17:05:22 +0900
From: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
To: Petr Mladek <pmladek@...e.com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Jiri Slaby <jslaby@...e.com>,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
Steven Rostedt <rostedt@...dmis.org>,
Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
linux-kernel@...r.kernel.org
Subject: Re: [RFC 3/3] sysrq: Warn about insufficient console_loglevel
On (01/11/19 17:20), Petr Mladek wrote:
> +static void warn_console(bool console_suppressed,
> + int orig_log_level,
> + struct sysrq_key_op *op_p)
> +{
> + static int warned;
> +
> + if (warned)
> + return;
> +
> + /* Do not warn when people are already setting loglevel via sysrq */
> + if (op_p->enable_mask & SYSRQ_ENABLE_LOG) {
> + warned = 1;
> + return;
> + }
> +
> + if (console_suppressed) {
> + pr_info("Messages filtered by console_loglevel (%d)%s\n",
> + orig_log_level,
> + sysrq_on_mask(SYSRQ_ENABLE_LOG) ? ", try SysRq+7" : "");
> + warned = 1;
> + }
> +}
I understand the intent.
Some comments:
- Not all of sysrq handlers printk() data. There are some quiet
handlers. E.g. sysrq_handle_unraw(). Having "Messages filtered by
console_loglevel" can be confusing.
- Not all sysrq handlers use INFO level.
E.g. sync_inodes_sb()->WARN_ON()->pr_warn(). So once again there can
be a "false positive" "Messages filtered" error, while in fact
no messages would be filtered out.
What do you think?
-ss
Powered by blists - more mailing lists