linux-kernel - Re: [PATCH 2/2] printk: make sure to print log on console.

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: <20180601093402.GB1841@jagdpanzerIV>
Date:   Fri, 1 Jun 2018 18:34:02 +0900
From:   Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
To:     Vaneet Narang <v.narang@...sung.com>
Cc:     Petr Mladek <pmladek@...e.com>,
        Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        Maninder Singh <maninder1.s@...sung.com>,
        "sergey.senozhatsky@...il.com" <sergey.senozhatsky@...il.com>,
        "rostedt@...dmis.org" <rostedt@...dmis.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        AMIT SAHRAWAT <a.sahrawat@...sung.com>,
        PANKAJ MISHRA <pankaj.m@...sung.com>
Subject: Re: [PATCH 2/2] printk: make sure to print log on console.

Hello,

On (06/01/18 14:12), Vaneet Narang wrote:
> > CPU0                            CPU1
> >
> > set console verbose
> >
> > dump_backtrace()
> > {
> >  // for (;;)  print frames
> >  printk("%pS\n", frame0);
> >  printk("%pS\n", frame1);
> >  printk("%pS\n", frame2);
> >  printk("%pS\n", frame3);
> >  ...                            console_loglevel = CONSOLE_LOGLEVEL_SILENT;
> >  printk("%pS\n", frame12);
> >  printk("%pS\n", frame13);
> > }
> >
> 
> This is not printk issue, its printk usage issue. User need to handle this part using some protection.
> 
> What we highlighted is issue related to printk, Where usage is correct 
> but still printk can miss some logs due to printk design of asynchronous printing.

Yeah, I understand your example from the commit message. What I said was
"the patch does not fully address the problem". One way or another we still
can miss logs due to the very same problem: either console_loglevel
manipulation on another CPU, or printk_safe(), etc. May be there other
scenarios that are broken.

So if we are going to apply the patch [I don't have real objections, and
Petr seems to be fine], then I'd probably ask for a better commit messages.
Namely, I really want to document cases that are not addressed and are
still known to be broken.

	-ss