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]

Message-ID: <20150420180904.GA19229@gmail.com>
Date:	Mon, 20 Apr 2015 20:09:04 +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, Apr 20, 2015 at 10:09:03AM -0700, Paul E. McKenney wrote:
> > 
> > The sysfs knob might be nice, but as far as I know nobody has been
> > complaining about it.
> > 
> > Besides, we already have the rcutree.kthread_prio= kernel-boot 
> > parameter. So how about if the Kconfig parameter selects either 
> > SCHED_OTHER (the default) or SCHED_FIFO:1, and then the boot 
> > parameter can be used to select other values.
> > 
> > That said, if the lack of a sysfs knob has been causing real 
> > problems, let's make that happen.
> 
> But then it's too late, because the time of something getting into 
> the kernel to the time people can use it can be months if not years.
> 
> I see no harm in adding one. Pretty much every kernel parameter I 
> added for ftrace, has a sysctrl knob for it. (Not a sysfs knob, but 
> a /proc/sys/kernel knob which is different).

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).

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.

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/