linux-kernel - Re: [GIT RFC PULL rcu/urgent] Prevent Kconfig from asking pointless questions

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:	Sat, 18 Apr 2015 15:03:41 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc:	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
	a.p.zijlstra@...llo.nl, akpm@...ux-foundation.org
Subject: Re: [GIT RFC PULL rcu/urgent] Prevent Kconfig from asking pointless
 questions


* Paul E. McKenney <paulmck@...ux.vnet.ibm.com> wrote:

> Hello, Ingo,
> 
> This series contains a single change that fixes Kconfig asking pointless
> questions (https://lkml.org/lkml/2015/4/14/616).  This is an RFC pull
> because there has not yet been a -next build for April 16th.  If you
> would prefer to wait until after -next has pulled this, please let me
> know and I will redo this pull request after that has happened.
> 
> In the meantime, this change is available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git for-mingo
> 
> for you to fetch changes up to 8d7dc9283f399e1fda4e48a1c453f689326d9396:
> 
>   rcu: Control grace-period delays directly from value (2015-04-14 19:33:59 -0700)
> 
> ----------------------------------------------------------------
> Paul E. McKenney (1):
>       rcu: Control grace-period delays directly from value
> 
>  kernel/rcu/tree.c | 16 +++++++++-------
>  lib/Kconfig.debug |  1 +
>  2 files changed, 10 insertions(+), 7 deletions(-)

Pulled, thanks a lot Paul!

Note, while this fixes Linus's immediate complaint that arose from the 
new option, I still think we need to do more fixes in this area.

To demonstrate the current situation I tried the following experiment, 
I did a 'make defconfig' on an x86 box and then took the .config and 
deleted all 'RCU Subsystem' options not marked as debugging.

Then I did a 'make oldconfig' to see what kinds of questions a user is 
facing when trying to configure RCU:

	*
	* Restart config...
	*
	*
	* RCU Subsystem
	*
	RCU Implementation
	> 1. Tree-based hierarchical RCU (TREE_RCU) (NEW)
	choice[1]: 1
	Task_based RCU implementation using voluntary context switch (TASKS_RCU) [N/y/?] (NEW) 
	Consider userspace as in RCU extended quiescent state (RCU_USER_QS) [N/y/?] (NEW) 
	Tree-based hierarchical RCU fanout value (RCU_FANOUT) [64] (NEW) 
	Tree-based hierarchical RCU leaf-level fanout value (RCU_FANOUT_LEAF) [16] (NEW) 
	Disable tree-based hierarchical RCU auto-balancing (RCU_FANOUT_EXACT) [N/y/?] (NEW) 
	Accelerate last non-dyntick-idle CPU's grace periods (RCU_FAST_NO_HZ) [N/y/?] (NEW) 
	Real-time priority to use for RCU worker threads (RCU_KTHREAD_PRIO) [0] (NEW) 
	Offload RCU callback processing from boot-selected CPUs (RCU_NOCB_CPU) [N/y/?] (NEW) 
	#
	# configuration written to .config
	#

Only TREE_RCU is available on defconfig, so all the other options 
marked with '(NEW)' were offered as an interactive prompt.

I don't think that any of the 8 interactive options (!) here are 
particularly useful to even advanced users who configure kernels, and 
I don't think they should be offered under non-expert settings.

Instead we should pick a preferred RCU configuration based on other 
hints (such as CONFIG_NR_CPUS and CONFIG_NO_HZ settings), and if users 
or distribution makers find some problem with that, we should address 
those specific complaints.

Making everything under the sun configurable, with which non-RCU 
experts cannot really do anything anyway, isn't very user friendly - 
and results in:

 - user confusion and frustration

 - possibly messed up configurations

 - it also hides inefficiencies that might arise from our defaults: 
   someone genuinely finding a problem might just tweak the .config, 
   without ever communicating that bad default to us.

So doing (much!) less is in general the best option for Kconfig driven 
UIs.

	Ingo
--
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/