linux-kernel - Re: [PATCH] printk: Ratelimit messages printed by console drivers

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: <20180423124502.423fb57thvbf3zet@pathway.suse.cz>
Date:   Mon, 23 Apr 2018 14:45:02 +0200
From:   Petr Mladek <pmladek@...e.com>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        akpm@...ux-foundation.org, linux-mm@...ck.org,
        Peter Zijlstra <peterz@...radead.org>, Jan Kara <jack@...e.cz>,
        Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
        Tejun Heo <tj@...nel.org>, linux-kernel@...r.kernel.org,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>
Subject: Re: [PATCH] printk: Ratelimit messages printed by console drivers

On Mon 2018-04-23 07:36:03, Steven Rostedt wrote:
> On Mon, 23 Apr 2018 12:32:32 +0200
> Ug, you're right. Somehow when I looked at where console_owner was set
> "console_lock_spinning_enabled" I saw it as "console_trylock_spinning".
> 
> This is what I get when I'm trying to follow three threads at the same
> time :-/

They are not easy to follow :-/

> > console_owner is really set only between:
> > 
> >     console_lock_spinning_enable()
> >     console_lock_spinning_disable_and_check()
> > 
> > and this entire section is called with interrupts disabled.
> 
> OK, I agree with you now. Although, one hour may still be too long.

I am not sure how slow are the slowest consoles. If I take that
everything should be faster than 1200 bauds. Then 10 minutes
should be enough for 1000 lines and 80 characters per-line:

   1000*80*8/1200/60 = 8.8888888

Alternatively, it seems that we are going to call console drivers
outside printk_safe context => the messages will appear in the main
log buffer immediately => only small risk of a ping-pong with printk
safe buffers. We might reset the counter when all messages are handled
in console_unlock(). It will be more complex patch than when using
ratelimiting but it still should be sane.

Neither solution is perfect. But I think that the recursion is not
worth any too complex solution.

Best Regards,
Petr