tree:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
head: 8b0eed9f6e36a5488967b0acc51444d658dd711b
commit: cc2ceda020c2d0ee9ea839fc0f4239a3f7055c95 [14074/14219] mm, oom: avoid printk()
iteration under RCU
reproduce:
# apt-get install sparse
# sparse version: v0.6.1-rc1-37-gd466a02-dirty
git checkout cc2ceda020c2d0ee9ea839fc0f4239a3f7055c95
make ARCH=x86_64 allmodconfig
make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp(a)intel.com>
sparse warnings: (new ones prefixed by >>)
include/linux/rcupdate.h:651:9: sparse: sparse: context imbalance in
'find_lock_task_mm' - wrong count at exit
include/linux/sched/mm.h:166:37: sparse: sparse: dereference of noderef expression
mm/oom_kill.c:219:28: sparse: sparse: context imbalance in 'oom_badness' -
unexpected unlock
> include/linux/rcupdate.h:651:9: sparse: sparse: context imbalance
in 'dump_tasks' - unexpected unlock
include/linux/rcupdate.h:651:9:
sparse: sparse: context imbalance in '__oom_kill_process' - unexpected unlock
vim +/dump_tasks +651 include/linux/rcupdate.h
^1da177e4c3f41 Linus Torvalds 2005-04-16 603
^1da177e4c3f41 Linus Torvalds 2005-04-16 604 /*
^1da177e4c3f41 Linus Torvalds 2005-04-16 605 * So where is rcu_write_lock()? It
does not exist, as there is no
^1da177e4c3f41 Linus Torvalds 2005-04-16 606 * way for writers to lock out RCU
readers. This is a feature, not
^1da177e4c3f41 Linus Torvalds 2005-04-16 607 * a bug -- this property is what
provides RCU's performance benefits.
^1da177e4c3f41 Linus Torvalds 2005-04-16 608 * Of course, writers must coordinate
with each other. The normal
^1da177e4c3f41 Linus Torvalds 2005-04-16 609 * spinlock primitives work well for
this, but any other technique may be
^1da177e4c3f41 Linus Torvalds 2005-04-16 610 * used as well. RCU does not care
how the writers keep out of each
^1da177e4c3f41 Linus Torvalds 2005-04-16 611 * others' way, as long as they do
so.
^1da177e4c3f41 Linus Torvalds 2005-04-16 612 */
3d76c082907e8f Paul E. McKenney 2009-09-28 613
3d76c082907e8f Paul E. McKenney 2009-09-28 614 /**
ca5ecddfa8fcbd Paul E. McKenney 2010-04-28 615 * rcu_read_unlock() - marks the end
of an RCU read-side critical section.
3d76c082907e8f Paul E. McKenney 2009-09-28 616 *
f27bc4873fa8b7 Paul E. McKenney 2014-05-04 617 * In most situations,
rcu_read_unlock() is immune from deadlock.
f27bc4873fa8b7 Paul E. McKenney 2014-05-04 618 * However, in kernels built with
CONFIG_RCU_BOOST, rcu_read_unlock()
f27bc4873fa8b7 Paul E. McKenney 2014-05-04 619 * is responsible for deboosting,
which it does via rt_mutex_unlock().
f27bc4873fa8b7 Paul E. McKenney 2014-05-04 620 * Unfortunately, this function
acquires the scheduler's runqueue and
f27bc4873fa8b7 Paul E. McKenney 2014-05-04 621 * priority-inheritance spinlocks.
This means that deadlock could result
f27bc4873fa8b7 Paul E. McKenney 2014-05-04 622 * if the caller of rcu_read_unlock()
already holds one of these locks or
ec84b27f9b3b56 Anna-Maria Gleixner 2018-05-25 623 * any lock that is ever acquired
while holding them.
f27bc4873fa8b7 Paul E. McKenney 2014-05-04 624 *
f27bc4873fa8b7 Paul E. McKenney 2014-05-04 625 * That said, RCU readers are never
priority boosted unless they were
f27bc4873fa8b7 Paul E. McKenney 2014-05-04 626 * preempted. Therefore, one way to
avoid deadlock is to make sure
f27bc4873fa8b7 Paul E. McKenney 2014-05-04 627 * that preemption never happens
within any RCU read-side critical
f27bc4873fa8b7 Paul E. McKenney 2014-05-04 628 * section whose outermost
rcu_read_unlock() is called with one of
f27bc4873fa8b7 Paul E. McKenney 2014-05-04 629 * rt_mutex_unlock()'s locks held.
Such preemption can be avoided in
f27bc4873fa8b7 Paul E. McKenney 2014-05-04 630 * a number of ways, for example, by
invoking preempt_disable() before
f27bc4873fa8b7 Paul E. McKenney 2014-05-04 631 * critical section's outermost
rcu_read_lock().
f27bc4873fa8b7 Paul E. McKenney 2014-05-04 632 *
f27bc4873fa8b7 Paul E. McKenney 2014-05-04 633 * Given that the set of locks
acquired by rt_mutex_unlock() might change
f27bc4873fa8b7 Paul E. McKenney 2014-05-04 634 * at any time, a somewhat more
future-proofed approach is to make sure
f27bc4873fa8b7 Paul E. McKenney 2014-05-04 635 * that that preemption never happens
within any RCU read-side critical
f27bc4873fa8b7 Paul E. McKenney 2014-05-04 636 * section whose outermost
rcu_read_unlock() is called with irqs disabled.
f27bc4873fa8b7 Paul E. McKenney 2014-05-04 637 * This approach relies on the fact
that rt_mutex_unlock() currently only
f27bc4873fa8b7 Paul E. McKenney 2014-05-04 638 * acquires irq-disabled locks.
f27bc4873fa8b7 Paul E. McKenney 2014-05-04 639 *
f27bc4873fa8b7 Paul E. McKenney 2014-05-04 640 * The second of these two approaches
is best in most situations,
f27bc4873fa8b7 Paul E. McKenney 2014-05-04 641 * however, the first approach can
also be useful, at least to those
f27bc4873fa8b7 Paul E. McKenney 2014-05-04 642 * developers willing to keep abreast
of the set of locks acquired by
f27bc4873fa8b7 Paul E. McKenney 2014-05-04 643 * rt_mutex_unlock().
f27bc4873fa8b7 Paul E. McKenney 2014-05-04 644 *
3d76c082907e8f Paul E. McKenney 2009-09-28 645 * See rcu_read_lock() for more
information.
3d76c082907e8f Paul E. McKenney 2009-09-28 646 */
bc33f24bdca8b6 Paul E. McKenney 2009-08-22 647 static inline void
rcu_read_unlock(void)
bc33f24bdca8b6 Paul E. McKenney 2009-08-22 648 {
f78f5b90c4ffa5 Paul E. McKenney 2015-06-18 649 RCU_LOCKDEP_WARN(!rcu_is_watching(),
bde23c6892878e Heiko Carstens 2012-02-01 650 "rcu_read_unlock() used
illegally while idle");
bc33f24bdca8b6 Paul E. McKenney 2009-08-22 @651 __release(RCU);
bc33f24bdca8b6 Paul E. McKenney 2009-08-22 652 __rcu_read_unlock();
d24209bb689e2c Paul E. McKenney 2015-01-21 653 rcu_lock_release(&rcu_lock_map);
/* Keep acq info for rls diags. */
bc33f24bdca8b6 Paul E. McKenney 2009-08-22 654 }
^1da177e4c3f41 Linus Torvalds 2005-04-16 655
:::::: The code at line 651 was first introduced by commit
:::::: bc33f24bdca8b6e97376e3a182ab69e6cdefa989 rcu: Consolidate sparse and lockdep
declarations in include/linux/rcupdate.h
:::::: TO: Paul E. McKenney <paulmck(a)linux.vnet.ibm.com>
:::::: CC: Ingo Molnar <mingo(a)elte.hu>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation