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
| ||
|
Date: Fri, 11 Nov 2016 19:16:44 +0100 From: Petr Mladek <pmladek@...e.com> To: Steven Rostedt <rostedt@...dmis.org> Cc: Linus Torvalds <torvalds@...ux-foundation.org>, Joe Perches <joe@...ches.com>, Andrew Morton <akpm@...ux-foundation.org>, Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>, Jason Wessel <jason.wessel@...driver.com>, Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.com>, Chris Mason <clm@...com>, Josef Bacik <jbacik@...com>, David Sterba <dsterba@...e.com>, linux-kernel@...r.kernel.org Subject: Re: [PATCH v2 3/4] printk/btrfs: Handle more message headers On Fri 2016-11-11 12:41:34, Steven Rostedt wrote: > On Wed, 9 Nov 2016 13:41:30 +0100 > Petr Mladek <pmladek@...e.com> wrote: > > > The commit 4bcc595ccd80decb4245096e ("printk: reinstate KERN_CONT for > > printing continuation lines") allows to define more message headers > > for a single message. The motivation is that continuous lines might > > get mixed. Therefore it make sense to define the right log level > > for every piece of a cont line. > > > > The current btrfs_printk() macros do not support continuous lines > > at the moment. But better be prepared for a custom messages and > > avoid potential "lvl" buffer overflow. > > > > This patch iterates over the entire message header. It is interested > > only into the message level like the original code. > > > > This patch also introduces PRINTK_MAX_SINGLE_HEADER_LEN. Three bytes > > are enough for the message level header at the moment. But it used to > > be three, see the commit 04d2c8c83d0e3ac5f ("printk: convert the format > > for KERN_<LEVEL> to a 2 byte pattern"). > > > > Also I fixed the default ratelimit level. It looked very strange > > when it was different from the default log level. > > > > Signed-off-by: Petr Mladek <pmladek@...e.com> > > --- > > fs/btrfs/super.c | 26 +++++++++++++++----------- > > include/linux/printk.h | 2 ++ > > 2 files changed, 17 insertions(+), 11 deletions(-) > > > > diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c > > index 74ed5aae6cea..c083d84eaa32 100644 > > --- a/fs/btrfs/super.c > > +++ b/fs/btrfs/super.c > > @@ -202,27 +202,31 @@ void __btrfs_handle_fs_error(struct btrfs_fs_info *fs_info, const char *function > > void btrfs_printk(const struct btrfs_fs_info *fs_info, const char *fmt, ...) > > { > > struct super_block *sb = fs_info->sb; > > - char lvl[4]; > > + char lvl[PRINTK_MAX_SINGLE_HEADER_LEN + 1]; > > struct va_format vaf; > > va_list args; > > - const char *type = logtypes[4]; > > + const char *type = NULL; > > int kern_level; > > struct ratelimit_state *ratelimit; > > > > va_start(args, fmt); > > > > - kern_level = printk_get_level(fmt); > > - if (kern_level) { > > + while ((kern_level = printk_get_level(fmt)) != 0) { > > size_t size = printk_skip_level(fmt) - fmt; > > - memcpy(lvl, fmt, size); > > - lvl[size] = '\0'; > > + > > + if (kern_level >= '0' || kern_level <= '7') { > > Shouldn't this be kernel_level >= '0' && kern_level <= '7' ? Great catch! I am idiot. I did all these patches in a hurry before the Plumber conference. I was blind when checking it later :-( Thanks a lot for such a careful review. Best Regards, Petr
Powered by blists - more mailing lists