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:	Mon, 20 Apr 2015 20:28:32 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Clark Williams <williams@...hat.com>,
	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
	a.p.zijlstra@...llo.nl, akpm@...ux-foundation.org,
	linux-rt-users@...r.kernel.org
Subject: Re: [GIT RFC PULL rcu/urgent] Prevent Kconfig from asking pointless
 questions


* Steven Rostedt <rostedt@...dmis.org> wrote:

> On Mon, 20 Apr 2015 20:09:04 +0200
> Ingo Molnar <mingo@...nel.org> wrote:
> 
> 
> > So the disadvantage is that if a boot default is wrong, we'll hear 
> > about it eventually and can fix/improve it.
> > 
> > If a sysctl knob is wrong, people will just 'tune' it and forget 
> > to propagate it to the kernel proper (why should they).
> 
> My fear is that there is no one true value. [...]

Do we know that?

> [...] One person complains about it, we change it, then someone else 
> complains about the new value. That would be even worse.

At that point we can still add a sysctl, if valid arguments are 
offered.

> > Which is fine for something like ftrace and other ad-hoc 
> > instrumentation that is generally very fine tuned to a given bug 
> > or given piece of hardware, but for something like the RCU 
> > implementation of the kernel - even if it's just a RT side thought 
> > of it - I'm not so sure about it.
> 
> I would argue than every case is different, and only the sysadmin 
> would know the right value. Thus, just set it to one, and if that's 
> not good enough, then the sysadmins can change it to their needs.

Well, we had really bad experience with sysctls in the past, in 
particular in the VM: with various settings exposed and distros 
'tuning' them - sometimes radically changing the way the system 
worked, confusing everyone involved.

So I'm in general opposed to sysctls for core kernel behavior - except 
for cases where we don't know better.

Instrumentation - especially instrumentation that should have been 
implemented mostly in user-space, like ftrace ;-) - is another special 
case that should stay as flexible as possible via sysctls, obviously.

Thanks,

	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/