Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 20 Jun 2017 13:50:19 -0400
From: Sandy Harris <>
To: Jeffrey Walton <>
Cc: "Theodore Ts'o" <>, "Jason A. Donenfeld" <>,, 
	David Miller <>, Linus Torvalds <>, 
	Eric Biggers <>, LKML <>, 
	Greg Kroah-Hartman <>,, 
	Linux Crypto Mailing List <>, Michael Ellerman <>
Subject: Re: Re: [PATCH] random: silence compiler warnings
 and fix race

On Tue, Jun 20, 2017 at 5:49 AM, Jeffrey Walton <> wrote:
> On Tue, Jun 20, 2017 at 5:36 AM, Theodore Ts'o <> wrote:
>> On Tue, Jun 20, 2017 at 10:53:35AM +0200, Jason A. Donenfeld wrote:

>>> > Suppressing all messages for all configurations cast a wider net than
>>> > necessary. Configurations that could potentially be detected and fixed
>>> > likely will go unnoticed. If the problem is not brought to light, then
>>> > it won't be fixed.

> Are there compelling reasons a single dmesg warning cannot be provided?
> A single message avoids spamming the logs. It also informs the system
> owner of the problem. An individual or organization can then take
> action based on their risk posture. Finally, it avoids the kernel
> making policy decisions for a user or organization.

I'd say the best solution is to have no configuration option
specifically for these messages. Always give some, but let
DEBUG_KERNEL control how many.

If DEBUG_KERNEL is not set, emit exactly one message & ignore any
other errors of this type. On some systems, that message may have to
be ignored, on some it might start an incremental process where one
problem gets fixed only to have another crop up & on some it might
prompt the admin to explore further by compiling with DEBUG_KERNEL.

If DEBUG_KERNEL is set, emit a message for every error of this type.

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.