linux-kernel - Re: [PATCH] printk/console: Do not suppress information about dropped messages

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190227084438.GA14252@jagdpanzerIV>
Date:   Wed, 27 Feb 2019 17:44:38 +0900
From:   Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
To:     John Ogness <john.ogness@...utronix.de>
Cc:     Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        Petr Mladek <pmladek@...e.com>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] printk/console: Do not suppress information about
 dropped messages

On (02/27/19 09:12), John Ogness wrote:
> >> 
> >> My only objection to this is that the "messages dropped" only comes if a
> >> non-supressed message comes. So information about dropped information
> >> may never get printed unless some task prints something non-supressed.
> >> 
> >> Imagine a situation where I am expecting a message to come, but don't
> >> see it because it was dropped. But if no more non-supressed messages
> >> come, I see neither the expected message nor the dropped message.
> >
> > I think this is exactly the problem (and thus the patch) we discussed
> > some 3 years ago.
> 
> I guess you are referring to this [0] thread.

Right.

[..]
> I would agree with the proposed solution from 2016. My experience is
> that the dropped messages are very important. Yes, printing them could
> lead to the loss of even more messages.

Yes, printing out messages does take time. But I think it's easier to
start losing messages due to preemption under console_sem than due to
call_console_drivers() latencies.

> But still, it is important information that needs to get out.

I'd agree. A summary "you lost %d messages somewhere between current
and previous messages" is surely better than what we have now, but is
still a bit less informative than "you lost %d messages just now".

	-ss