lkml.org 
[lkml]   [2020]   [Sep]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH next v2 1/2] printk: avoid and/or handle record truncation
Date
On 2020-09-30, Petr Mladek <pmladek@suse.com> wrote:
> Anyway, I see hardcoded limit more like a hack. It limits something
> somewhere so that some other code somewhere else is safe to use.
>
> And printk.c is really bad from this point. It sometimes does not
> check for overflow because it "knows" that the buffers are big
> enough. But it is error prone code, especially when there are more
> limits defined (pure text, prefix, extended prefix). And it
> will be worse if we allow to add more optional information
> into the prefix.

So should I post a v3 where the checks are added? Or should I add
comments where checks would be, explaining why the checks are not
needed?

John Ogness

\
 
 \ /
  Last update: 2020-09-30 13:43    [W:0.052 / U:8.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site