linux-kernel - Re: [RFC GIT PULL, v2] RCU changes for v4.12

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:   Wed, 10 May 2017 12:54:40 -0700
From:   "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Ingo Molnar <mingo@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <a.p.zijlstra@...llo.nl>,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [RFC GIT PULL, v2] RCU changes for v4.12

On Wed, May 10, 2017 at 10:27:24AM -0700, Linus Torvalds wrote:

[ . . . ]

> parts, namely how the RCU changes apparently mess with the DRM
> selftest changes.

I am testing a merge with current linus/master, and I looked through
the commits in -next selected by:

	gitk v4.11.. --no-merges --all-match --grep=drm --grep=selftest

I didn't find anything obvious.  If the tests complete successfully,
I will try running the DRM selftest.

[ . . . ]

> And for Paul: the RCU subsystem is starting to get ridiculous. Seriously.
> 
> That is *particularly* true for srcu. We don't even have all that many
> users, and I suspect a large subset of those users are just crap to
> begin with. The biggest reason for srcu seems to be bad callbacks,
> particularly shit like the mmu notifier code. Things that we probably
> shouldn't have done in the first place, and where srcu just encouraged
> people to do bad things.
> 
> Seriously, do this:
> 
>    git grep srcu.*lock -- :^Documentation/ :^kernel/rcu/
> 
> and notice that we have only a few hundred lines in the kernel that do
> srcu locking. kvm seems to be the main big user.
> 
> This annoys me, because the main reason people use srcu is bad design
> and lazyness, where they can't be arsed to try to minimize locking and
> sleeping things.  The "sleeping callbacks" in particular tend to be a
> huge design mistake.
> 
> Yet, despite this fairly limited use, rscu seems to be just growing
> and bloating, and making more and more excuses fro bad behavior.

I can certainly revisit the uses.  If it ends up that no SRCU users
really need SRCU, then it should of course be removed.

> And it was *years* since I asked you to look at getting rid of the
> absolutely insane proliferations of different RCU models. I don't
> think anything ever happened. We *still* have TREE_RCU,| PREEMPT_RCU,
> and TINY_SRCU.

I did remove TINY_PREEMPT_RCU in response to your request.

I have also removed the Kconfig parameters SRCU_SYNCHRONIZE_DELAY,
RCU_CPU_STALL_DETECTOR, PROVE_RCU_DELAY, RCU_CPU_STALL_VERBOSE,
CONFIG_RCU_FANOUT_EXACT, CONFIG_RCU_CPU_STALL_INFO, and
RCU_TORTURE_TEST_RUNNABLE.  There are quite a few more that could
be removed:

o	RCU_TORTURE_TEST_SLOW_PREINIT, RCU_TORTURE_TEST_SLOW_PREINIT_DELAY,
	RCU_TORTURE_TEST_SLOW_PREINIT_DELAY, RCU_TORTURE_TEST_SLOW_INIT,
	RCU_TORTURE_TEST_SLOW_INIT_DELAY, RCU_TORTURE_TEST_SLOW_CLEANUP,
	and RCU_TORTURE_TEST_SLOW_CLEANUP_DELAY.  I will queue patches
	to remove these.

o	I believe that RCU_CPU_STALL_TIMEOUT could be dropped in favor
	of the existing rcupdate.rcu_cpu_stall_timeout kernel parameter,
	I will queue a patch and see if anyone screams.

o	RCU_KTHREAD_PRIO could be dropped in favor of the existing
	rcutree.kthread_prio kernel parameter.  I will queue a patch,
	and I would be very surprised if anyone screamed.

o	RCU_BOOST_DELAY could be a boot parameter.  I will queue a
	patch.

o	I believe that PROVE_RCU_REPEATEDLY could be a boot parameter,
	I will queue a patch and see if anyone screams.

o	Not sure about SPARSE_RCU_POINTER, will try making this
	unconditional and see if anyone screams.

o	It might be possible to eliminate RCU_NOCB_CPU_NONE,
	RCU_NOCB_CPU_ZERO, and RCU_NOCB_CPU_ALL.  I will look
	into this.

> And with this pull request we now have CLASSIC_SRCU, TINY_SRCU,
> TREE_SRCU and TASKS_RCU.

I have a calendar reminder to remove CLASSIC_SRCU near the end of this
year.  Given the testing results thus far, I would be happy to remove
it sooner if you would prefer.

> That's in addition to all the other insane tweaks that nobody uses (eg
> RCU_FANOUT etc) and that I made sure got removed from any sane
> questionnaire.

I use RCU_FANOUT and RCU_FANOUT_LEAF to test code paths on small systems
that would otherwise only be exercised on systems with thousands of CPUs.
I am not aware of any other use.  If it would help, I would be happy to
move them to lib/Kconfig.debug and make them depend on TORTURE_TEST.

> Paul, this really needs to stop.
> 
> I'm now going to stop pulling any more crazy RCU crap. Seriously. If
> the RCU subsystem doesn't start shrinking, I'm no longer pulling. Send
> me fixes, but don't send me more of this crazy stuff.
> 
> So this is me putting my foot down. I should have done it long ago.
> I'm done with crazy. Don't waste your time doing yet another RCU mode,
> because I will not take it. And don't waste your time expanding on the
> existing ones without looking at which of those things can be removed.

OK, nothing more from RCU other than fixes, code reduction, and
documentation for the time being.

							Thanx, Paul