lkml.org 
[lkml]   [2020]   [Sep]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH next v2 1/2] printk: avoid and/or handle record truncation
On Wed 2020-09-30 13:48:56, John Ogness wrote:
> 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?

If you have these locations still in head then it would be nice
to add the checks.

But it is not urgent. We should be on the safe side. Both ways
to store new messages are limited again now.

Anyway, please do so in a followup patch. I would like to push this
patchset into linux-next ASAP so that the robots could continue
finding new bugs.

Best Regards,
Petr

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