linux-kernel - Re: [PATCH] make CONFIG_EXPERIMENTAL invisible and default

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]

Date:	Sun, 7 Oct 2012 09:30:29 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Dave Airlie <airlied@...il.com>
Cc:	Frederic Weisbecker <fweisbec@...il.com>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Kees Cook <keescook@...omium.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-kernel@...r.kernel.org,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Serge Hallyn <serge.hallyn@...onical.com>,
	"David S. Miller" <davem@...emloft.net>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] make CONFIG_EXPERIMENTAL invisible and default

On Sun, Oct 07, 2012 at 12:33:48PM +1000, Dave Airlie wrote:
> >>
> >> Really I would much prefer to add some "Don't enable it unless you're
> >> doing kernel hacking.
> >> If unsure say N" text in the Kconfig.
> >>
> >> I can understand that distros want to cover as much feature as they
> >> can for their users. But
> >> should it be an excuse for not reading outstanding warnings in Kconfig
> >> help text?
> >
> > In my experience, they do not read these warnings carefully.  :-(
> > Or perhaps they do read them, but react to them by running the code
> > through some test suite rather than by putting full faith in the
> > warning.
> 
> I think Kconfig is mostly what distro would like to use the thing is
> the Kconfig text needs to be there upfront when its merged, not two
> months later, since then it too late for a distro to notice.
> 
> I'd bet most distros would read the warnings, but in a lot of cases
> the warning don't exist until its too late.

In the case of CONFIG_RCU_USER_QS you are quite right, the warning
should have been there from the beginning and was not.  I suppose you
could argue that the warning was not sufficiently harsh in the case of
CONFIG_RCU_FAST_NO_HZ, but either way it did get ignored:

config RCU_FAST_NO_HZ
	bool "Accelerate last non-dyntick-idle CPU's grace periods"
	depends on TREE_RCU && NO_HZ && SMP
	default n
	help
	  This option causes RCU to attempt to accelerate grace periods
	  in order to allow the final CPU to enter dynticks-idle state
	  more quickly.  On the other hand, this option increases the
	  overhead of the dynticks-idle checking, particularly on systems
	  with large numbers of CPUs.

	  Say Y if energy efficiency is critically important, particularly
	  	if you have relatively few CPUs.

	  Say N if you are unsure.

I have since made RCU_FAST_NO_HZ more generally applicable, so it is
OK to enable now.  I suppose I need to update the help text...

Either way, however, it would be good to tag an experimental config
option at boot time.  Even if the help text gives very clear warnings,
it would be good to have the option defend itself against the occasional
inevitable typo.

							Thanx, Paul

> Dave.
> 
> 
> >> Or may be add some specific warning yeah. I wouldn't mind much.
> >
> > We have some weeks to think about it -- I cannot see pushing a
> > warning in as a regression.  ;-)
> >
> >                                                         Thanx, Paul
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@...r.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/