Re: [RFC PATCH] x86, mce: change the mce notifier to 'blocking' from 'atomic'

["Paul E. McKenney" <paulmck@linux.vnet.ibm.com>]

On Wed, Apr 12, 2017 at 03:42:32PM -0700, Paul E. McKenney wrote:
> On Wed, Apr 12, 2017 at 11:50:45PM +0200, Thomas Gleixner wrote:
> > On Wed, 12 Apr 2017, Borislav Petkov wrote:
> > 
> > > On Wed, Apr 12, 2017 at 08:27:05PM +0000, Verma, Vishal L wrote:
> > > > But isn't the atomic notifier call chain always called in atomic
> > > > context?
> > > 
> > > No, it isn't. We're calling it in normal process context in
> > > mce_gen_pool_process() too.
> > > 
> > > So this early exit will avoid any sleeping in atomic context. And since
> > > there's nothing you can do about the errors reported in atomic context,
> > > we can actually use that fact.
> > 
> > No, you can't.
> > 
> > CONFIG_RCU_PREEMPT=n + CONFIG_PREEMPT_COUNT will disable preemption from
> > within __atomic_notifier_call_chain() via rcu_read_lock(). Ergo you wont
> > ever enter the handler.
> > 
> > The behaviour in the RCU code is inconsistent. CONFIG_RCU_PREEMPT=y does
> > obviouly not disable preemption, but it should still trigger the
> > might_sleep() check when a blocking function is called from within a rcu
> > read side critical section.
> 
> Maybe something like the (untested) patch below.  Please note that this
> would need some help to work correctly in -rt.  This applies only against
> -rcu tip, but in that case you can just get it directly from -rcu.

So I injected a schedule_timeout_interruptible() into rcutorture's RCU
read-side critical section, and the patch complained as expected.  But is
also got a "scheduling while atomic" and a "DEBUG_LOCKS_WARN_ON(val >
preempt_count())" and a warning at "kernel/time/timer.c:1275", which
is this:

	if (count != preempt_count()) {
		WARN_ONCE(1, "timer: %pF preempt leak: %08x -> %08x\n",
			  fn, count, preempt_count());
		/*
		 * Restore the preempt count. That gives us a decent
		 * chance to survive and extract information. If the
		 * callback kept a lock held, bad luck, but not worse
		 * than the BUG() we had.
		 */
		preempt_count_set(count);
	}

So you are saying that you are seeing blocking in RCU-preempt read-side
critical sections being ignored?

Here is the Kconfig fragment used by this test:

	CONFIG_SMP=y
	CONFIG_NR_CPUS=8
	CONFIG_PREEMPT_NONE=n
	CONFIG_PREEMPT_VOLUNTARY=n
	CONFIG_PREEMPT=y
	#CHECK#CONFIG_PREEMPT_RCU=y
	CONFIG_HZ_PERIODIC=n
	CONFIG_NO_HZ_IDLE=y
	CONFIG_NO_HZ_FULL=n
	CONFIG_RCU_FAST_NO_HZ=n
	CONFIG_RCU_TRACE=n
	CONFIG_HOTPLUG_CPU=n
	CONFIG_SUSPEND=n
	CONFIG_HIBERNATION=n
	CONFIG_RCU_FANOUT=3
	CONFIG_RCU_FANOUT_LEAF=3
	CONFIG_RCU_NOCB_CPU=n
	CONFIG_DEBUG_LOCK_ALLOC=y
	CONFIG_PROVE_LOCKING=n
	CONFIG_RCU_BOOST=n
	CONFIG_RCU_EXPERT=y
	CONFIG_RCU_TORTURE_TEST_SLOW_CLEANUP=y
	CONFIG_RCU_TORTURE_TEST_SLOW_INIT=y
	CONFIG_RCU_TORTURE_TEST_SLOW_PREINIT=y
	CONFIG_DEBUG_OBJECTS=y
	CONFIG_DEBUG_OBJECTS_RCU_HEAD=y

I will run other scenarios overnight.

							Thanx, Paul

_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm