[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c5b5d660-d217-35f0-c4f1-7252367934d1@i-love.sakura.ne.jp>
Date: Mon, 10 Dec 2018 23:01:39 +0900
From: Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
To: Petr Mladek <pmladek@...e.com>
Cc: Dmitry Vyukov <dvyukov@...gle.com>,
Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
Steven Rostedt <rostedt@...dmis.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>,
syzkaller <syzkaller@...glegroups.com>
Subject: Re: [PATCH] printk: Add caller information to printk() output.
On 2018/12/10 22:09, Petr Mladek wrote:
>> +#ifdef CONFIG_PRINTK_FROM
>> +#define PREFIX_FROM_MAX 16
>> +#define PREFIX_MAX (32 + PREFIX_FROM_MAX)
>> +#define LOG_LINE_MAX (1024 - 32)
>
> This looks suspicious. We either need to limit LOG_LINE_MAX
> by the real PREFIX_MAX (48). Or we must make sure that
> the code is able to handle an eventual overflow.
Reducing LOG_LINE_MAX makes devkmsg_write() to return -EINVAL.
Is such user visible change acceptable?
> BTW: The limit 48 looks right. If I count correctly, the longest
> prefix might be:
>
> <2048>[4294967296,xxxxxx][T4294967296]
>
> 38 = 6+19+13
Theoretical max (based on variable's bit width) is
6 + 20 + 13 + 1 (for space) + 1 (for '\0') = 41.
We allocate 32 for "<2047>[18446744073.709551] ". Thus,
I chose 48 for "<2047>[18446744073.709551][T4294967295] ".
Powered by blists - more mailing lists