CC: [email protected] In-Reply-To: <[email protected]> References: <[email protected]> TO: Yonghong Song <[email protected]> TO: [email protected] TO: [email protected] CC: Alexei Starovoitov <[email protected]> CC: Daniel Borkmann <[email protected]> CC: [email protected] CC: Martin KaFai Lau <[email protected]>
Hi Yonghong, I love your patch! Perhaps something to improve: [auto build test WARNING on bpf-next/master] url: https://github.com/0day-ci/linux/commits/Yonghong-Song/bpf-using-rcu_read_lock-for-bpf_sk_storage_map-iterator/20200915-024727 base: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git master :::::: branch date: 16 hours ago :::::: commit date: 16 hours ago config: i386-randconfig-s001-20200914 (attached as .config) compiler: gcc-9 (Debian 9.3.0-15) 9.3.0 reproduce: # apt-get install sparse # sparse version: v0.6.2-191-g10164920-dirty # save the attached .config to linux build tree make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=i386 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot <[email protected]> sparse warnings: (new ones prefixed by >>) net/core/bpf_sk_storage.c: note: in included file (through include/linux/rculist.h): >> include/linux/rcupdate.h:686:9: sparse: sparse: context imbalance in >> 'bpf_sk_storage_map_seq_find_next' - unexpected unlock include/linux/rcupdate.h:686:9: sparse: sparse: context imbalance in 'bpf_sk_storage_map_seq_stop' - unexpected unlock # https://github.com/0day-ci/linux/commit/a9b8e045577010eb33328af8e1a226f29c432afd git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Yonghong-Song/bpf-using-rcu_read_lock-for-bpf_sk_storage_map-iterator/20200915-024727 git checkout a9b8e045577010eb33328af8e1a226f29c432afd vim +/bpf_sk_storage_map_seq_find_next +686 include/linux/rcupdate.h ^1da177e4c3f41 Linus Torvalds 2005-04-16 638 ^1da177e4c3f41 Linus Torvalds 2005-04-16 639 /* ^1da177e4c3f41 Linus Torvalds 2005-04-16 640 * So where is rcu_write_lock()? It does not exist, as there is no ^1da177e4c3f41 Linus Torvalds 2005-04-16 641 * way for writers to lock out RCU readers. This is a feature, not ^1da177e4c3f41 Linus Torvalds 2005-04-16 642 * a bug -- this property is what provides RCU's performance benefits. ^1da177e4c3f41 Linus Torvalds 2005-04-16 643 * Of course, writers must coordinate with each other. The normal ^1da177e4c3f41 Linus Torvalds 2005-04-16 644 * spinlock primitives work well for this, but any other technique may be ^1da177e4c3f41 Linus Torvalds 2005-04-16 645 * used as well. RCU does not care how the writers keep out of each ^1da177e4c3f41 Linus Torvalds 2005-04-16 646 * others' way, as long as they do so. ^1da177e4c3f41 Linus Torvalds 2005-04-16 647 */ 3d76c082907e8f Paul E. McKenney 2009-09-28 648 3d76c082907e8f Paul E. McKenney 2009-09-28 649 /** ca5ecddfa8fcbd Paul E. McKenney 2010-04-28 650 * rcu_read_unlock() - marks the end of an RCU read-side critical section. 3d76c082907e8f Paul E. McKenney 2009-09-28 651 * f27bc4873fa8b7 Paul E. McKenney 2014-05-04 652 * In most situations, rcu_read_unlock() is immune from deadlock. f27bc4873fa8b7 Paul E. McKenney 2014-05-04 653 * However, in kernels built with CONFIG_RCU_BOOST, rcu_read_unlock() f27bc4873fa8b7 Paul E. McKenney 2014-05-04 654 * is responsible for deboosting, which it does via rt_mutex_unlock(). f27bc4873fa8b7 Paul E. McKenney 2014-05-04 655 * Unfortunately, this function acquires the scheduler's runqueue and f27bc4873fa8b7 Paul E. McKenney 2014-05-04 656 * priority-inheritance spinlocks. This means that deadlock could result f27bc4873fa8b7 Paul E. McKenney 2014-05-04 657 * if the caller of rcu_read_unlock() already holds one of these locks or ec84b27f9b3b56 Anna-Maria Gleixner 2018-05-25 658 * any lock that is ever acquired while holding them. f27bc4873fa8b7 Paul E. McKenney 2014-05-04 659 * f27bc4873fa8b7 Paul E. McKenney 2014-05-04 660 * That said, RCU readers are never priority boosted unless they were f27bc4873fa8b7 Paul E. McKenney 2014-05-04 661 * preempted. Therefore, one way to avoid deadlock is to make sure f27bc4873fa8b7 Paul E. McKenney 2014-05-04 662 * that preemption never happens within any RCU read-side critical f27bc4873fa8b7 Paul E. McKenney 2014-05-04 663 * section whose outermost rcu_read_unlock() is called with one of f27bc4873fa8b7 Paul E. McKenney 2014-05-04 664 * rt_mutex_unlock()'s locks held. Such preemption can be avoided in f27bc4873fa8b7 Paul E. McKenney 2014-05-04 665 * a number of ways, for example, by invoking preempt_disable() before f27bc4873fa8b7 Paul E. McKenney 2014-05-04 666 * critical section's outermost rcu_read_lock(). f27bc4873fa8b7 Paul E. McKenney 2014-05-04 667 * f27bc4873fa8b7 Paul E. McKenney 2014-05-04 668 * Given that the set of locks acquired by rt_mutex_unlock() might change f27bc4873fa8b7 Paul E. McKenney 2014-05-04 669 * at any time, a somewhat more future-proofed approach is to make sure f27bc4873fa8b7 Paul E. McKenney 2014-05-04 670 * that that preemption never happens within any RCU read-side critical f27bc4873fa8b7 Paul E. McKenney 2014-05-04 671 * section whose outermost rcu_read_unlock() is called with irqs disabled. f27bc4873fa8b7 Paul E. McKenney 2014-05-04 672 * This approach relies on the fact that rt_mutex_unlock() currently only f27bc4873fa8b7 Paul E. McKenney 2014-05-04 673 * acquires irq-disabled locks. f27bc4873fa8b7 Paul E. McKenney 2014-05-04 674 * f27bc4873fa8b7 Paul E. McKenney 2014-05-04 675 * The second of these two approaches is best in most situations, f27bc4873fa8b7 Paul E. McKenney 2014-05-04 676 * however, the first approach can also be useful, at least to those f27bc4873fa8b7 Paul E. McKenney 2014-05-04 677 * developers willing to keep abreast of the set of locks acquired by f27bc4873fa8b7 Paul E. McKenney 2014-05-04 678 * rt_mutex_unlock(). f27bc4873fa8b7 Paul E. McKenney 2014-05-04 679 * 3d76c082907e8f Paul E. McKenney 2009-09-28 680 * See rcu_read_lock() for more information. 3d76c082907e8f Paul E. McKenney 2009-09-28 681 */ bc33f24bdca8b6 Paul E. McKenney 2009-08-22 682 static inline void rcu_read_unlock(void) bc33f24bdca8b6 Paul E. McKenney 2009-08-22 683 { f78f5b90c4ffa5 Paul E. McKenney 2015-06-18 684 RCU_LOCKDEP_WARN(!rcu_is_watching(), bde23c6892878e Heiko Carstens 2012-02-01 685 "rcu_read_unlock() used illegally while idle"); bc33f24bdca8b6 Paul E. McKenney 2009-08-22 @686 __release(RCU); bc33f24bdca8b6 Paul E. McKenney 2009-08-22 687 __rcu_read_unlock(); d24209bb689e2c Paul E. McKenney 2015-01-21 688 rcu_lock_release(&rcu_lock_map); /* Keep acq info for rls diags. */ bc33f24bdca8b6 Paul E. McKenney 2009-08-22 689 } ^1da177e4c3f41 Linus Torvalds 2005-04-16 690 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/[email protected]
.config.gz
Description: application/gzip
_______________________________________________ kbuild mailing list -- [email protected] To unsubscribe send an email to [email protected]
