linux-kernel - Re: [PATCH] printk: Add loglevel for "do not print to consoles".

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <36db0dfe-9d7e-0616-cbe6-4bfb99a1f470@i-love.sakura.ne.jp>
Date:   Thu, 7 May 2020 14:13:34 +0900
From:   Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
To:     Joe Perches <joe@...ches.com>
Cc:     Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Petr Mladek <pmladek@...e.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        linux-kernel@...r.kernel.org, Dmitry Safonov <dima@...sta.com>,
        Michal Hocko <mhocko@...e.com>,
        Yafang Shao <laoar.shao@...il.com>
Subject: Re: [PATCH] printk: Add loglevel for "do not print to consoles".

On 2020/05/07 10:02, Joe Perches wrote:
>>> printk_get_level / printk_skip_level and the various
>>> uses of %pV using printk_get_level
>>>
>>
>> Excuse me, but what do you mean?
>>
>> I wish printk() accepts "loglevel" argument detached from "fmt" argument (e.g.
> 
> I think that's a bad idea as it would expand
> _every_ use of printk with another argument
> and overall code size would increase for very
> little value.

I'm not saying that we should add loglevel argument to all printk() callers.
I'm saying that we could add a variant of printk() which accepts loglevel
argument (say, e.g. printkl() and vprintkl()).

I think that some of printk_get_level() users are using printk_get_level() only
for detaching loglevel argument from fmt argument.

For example, fs/f2fs/f2fs.h defines f2fs_{err,warn,notice,info,debug}() which pass
KERN_* to f2fs_printk(), but f2fs_printk() in fs/f2fs/super.c trims KERN_* and passes
it back to printk(). If printkl() were there, f2fs_err() etc. can directly call
printkl() (and avoids printk_get_level(), printk_skip_level() and "struct va_format").

fs/btrfs/ctree.h similarly defines btrfs_{emerg,alert,crit,err,warn,notice,info}() and
their RCU and latelimited variants which pass KERN_* to btrfs_printk(), but
btrfs_printk() in fs/btrfs/super.c trims KERN_* and passes it back to printk().
If printkl() were there, btrfs_emerg() etc. can avoid printk_get_level() and
printk_skip_level().

sound/core/misc.c defines __snd_printk() which allows inserting filename and line number.
If printkl() were there, __snd_printk() can avoid printk_get_level() and printk_skip_level(),
and can constify format argument variable (which is currently writable just in order to embed
loglevel argument).

I don't know how the lockless logbuf will replace printk_safe_flush_buffer(). But I guess
it is possible to avoid printk_safe_flush_buffer() and printk_skip_level() as demonstrated
by https://lkml.kernel.org/r/5e192ca2-3b24-0b45-fc13-51feec43c216@i-love.sakura.ne.jp .

Then, printk_skip_headers() will be the only user of printk_skip_level(). I don't know how
vkdb_printf() works, but vkdb_printf() is currently using printk_skip_level() in order to
remove loglevel argument. We can avoid printk_skip_level() if loglevel argument is detached
 from fmt argument.

> 
> And do look at the code and uses of printk_get_level.

And again, what am I missing?