linux-kernel - Re: [PATCH -v3 1/2] ratelimit: Extend to print suppressed messages on release

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: <577C2542.9010008@de.ibm.com>
Date:	Tue, 5 Jul 2016 23:23:14 +0200
From:	Christian Borntraeger <borntraeger@...ibm.com>
To:	Paolo Bonzini <pbonzini@...hat.com>, Joe Perches <joe@...ches.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Borislav Petkov <bp@...en8.de>,
	Radim Krčmář <rkrcmar@...hat.com>,
	Cornelia Huck <cornelia.huck@...ibm.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Franck Bui <fbui@...e.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Ingo Molnar <mingo@...nel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Uwe Kleine-König <u.kleine-koenig@...gutronix.de>,
	Janosch Frank <frankja@...ux.vnet.ibm.com>
Subject: Re: [PATCH -v3 1/2] ratelimit: Extend to print suppressed messages on
 release

On 07/05/2016 11:14 PM, Paolo Bonzini wrote:
> 
> 
> On 05/07/2016 22:53, Christian Borntraeger wrote:
>> Yes, this is new in next. As far as I can see, the new message would only
>> appear if we would call ratelimit_state_exit. Correct? We do not call this -
>> I assume this is ok?
>>
>> We really only want to reuse the rate limit base code (to avoid writing the same
>> code twice) and being in lib indicated that this can indeed be used outside
>> printk.
>> Now: your patch 1 would allow me to get rid of the messages completely
>> by setting the flag and by not calling ratelimit_state_exit. Which is probably
>> what we should do in our code.
> 
> Can we delay fixing this after the code is merged in Linus's tree?

Absolutely. We already have 2 smaller conflicts in next and I certainly do not want to add
another one.

The current ratelimit print does not hurt - it is just not necessary for us.
so my statement was just a "statement of direction" to write some IBM speak ;-)