Messages in this thread | | | Date | Fri, 5 Oct 2012 09:46:42 -0700 | From | "Paul E. McKenney" <> | Subject | Re: [PATCH] make CONFIG_EXPERIMENTAL invisible and default |
| |
On Thu, Oct 04, 2012 at 07:31:50AM -0700, Paul E. McKenney wrote: > On Thu, Oct 04, 2012 at 02:55:39AM +0100, Matthew Garrett wrote: > > On Wed, Oct 03, 2012 at 01:03:14PM -0700, Paul E. McKenney wrote: > > > > > That has not proven sufficient for me in the past, RCU_FAST_NO_HZ > > > being a case in point. > > > > Taint the kernel at boot time? That'd be sufficient to force distros to > > disable it. > > Cool! That does sound much more socially responsible than my thought > of forcing a splat (e.g., WARN_ON(1)) during boot. ;-)
So, from what I can see, here is the list of the ways of warning distros off of a given kernel config option, taken in terms of CONFIG_RCU_USER_QS:
1. Make CONFIG_RCU_USER_QS depend on CONFIG_BROKEN.
It sounds to me like distros would avoid adding this (do they?), but tester would probably avoid it as well.
2. Make CONFIG_RCU_USER_QS depend on CONFIG_STAGING.
As Frederic noted, this is more of a driver thing than a core-kernel thing, so probably not appropriate.
3. Boot-time WARN_ON() if CONFIG_RCU_USER_QS=y.
This seems to me to be a tad excessive. But the place to do it might be rcu_bootup_announce_oddness() in kernel/rcutree_plugin.h.
4. Remove CONFIG_RCU_USER_QS from Kconfig, so that users have to patch their kernel to enable it.
This also seems a tad excessive.
5. Maintain CONFIG_RCU_USER_QS out of tree, for example in the -rt patchset.
This is a good place to start, but it has been where CONFIG_RCU_USER_QS has been for some time, and although it got some good testing, it clearly needs more. In my view, CONFIG_RCU_USER_QS has outgrown its out-of-tree roots.
6. Boot-time add_taint() if CONFIG_RCU_USER_QS=y, as suggested by Matthew Garrett. The taint value might be TAINT_CRAP, TAINT_OOT_MODULE, TAINT_WARN, or TAINT_FIRMWARE_WORKAROUND -- all the other taint values disable lockdep. Of these four, TAINT_OOT_MODULE and TAINT_FIRMWARE_WORKAROUND are clearly off-topic, leaving TAINT_CRAP and TAINT_WARN. Taking them one at a time:
TAINT_CRAP: Used when loading modules from staging.
TAINT_WARN: Used when "scheduling while atomic" is encountered.
So I have my tongue only halfway in my cheek when I suggest starting with TAINT_CRAP, then moving to TAINT_WARN, then removing the tainting altogether. The place to do this might be rcu_bootup_announce_oddness() in kernel/rcutree_plugin.h.
So how about the following progression?
A. Early days, only a few crazies should test. In this case, the code should be out of tree, perhaps in something like -rt, perhaps as a set of patches.
B. Need more testers, but still not expected to work reasonably. Mainline, but depending on CONFIG_BROKEN. (I am not all that enthusiastic about this option, but am including it for completeness.)
C. Need wide testing, but don't want 100,000,000 unsuspecting test subjects. Taint the kernel with TAINT_CRAP.
D. OK for production in special situations, but definitely not for typical users. Taint the kernel with TAINT_WARN.
E. Ready for general production use. Mainlined without restrictions.
I would say that CONFIG_RCU_USER_QS is currently at point C above, it clearly now needs testing on a wide variety of hardware, but also is clearly not ready for 100,000,000 users.
Thoughts?
Thanx, Paul
| |