From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933941AbcKMMza (ORCPT ); Sun, 13 Nov 2016 07:55:30 -0500 Received: from www262.sakura.ne.jp ([202.181.97.72]:15241 "EHLO www262.sakura.ne.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933391AbcKMMz2 (ORCPT ); Sun, 13 Nov 2016 07:55:28 -0500 To: paulmck@linux.vnet.ibm.com Cc: josh@joshtriplett.org, rostedt@goodmis.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, linux-kernel@vger.kernel.org Subject: Re: [srcu] Can we suppress sparse warning? From: Tetsuo Handa References: <201611092036.DAJ05243.HOOMQSVOJFFLtF@I-love.SAKURA.ne.jp> <20161109185810.GM4127@linux.vnet.ibm.com> <201611122326.GGI69239.OJLFtQVFMHOFSO@I-love.SAKURA.ne.jp> <20161112191732.GB4127@linux.vnet.ibm.com> In-Reply-To: <20161112191732.GB4127@linux.vnet.ibm.com> Message-Id: <201611132155.BCA46603.HOVtQSFOOFMLFJ@I-love.SAKURA.ne.jp> X-Mailer: Winbiff [Version 2.51 PL2] X-Accept-Language: ja,en,zh Date: Sun, 13 Nov 2016 21:55:10 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Paul E. McKenney wrote: > On Sat, Nov 12, 2016 at 11:26:15PM +0900, Tetsuo Handa wrote: > > Both head->r.acl and &tomoyo_kernel_namespace.policy_list[TOMOYO_ID_MANAGER]->next > > refer normal kernel address space. Thus, I think that this warning is a false positive. > > > > This warning goes away if I disable rcu_dereference_sparse() call in > > __rcu_dereference_check() from srcu_dereference_check() from srcu_dereference(). > > > > --- a/include/linux/rcupdate.h > > +++ b/include/linux/rcupdate.h > > @@ -605,7 +605,7 @@ static inline void rcu_preempt_sleep_check(void) > > /* Dependency order vs. p above. */ \ > > typeof(*p) *________p1 = (typeof(*p) *__force)lockless_dereference(p); \ > > RCU_LOCKDEP_WARN(!(c), "suspicious rcu_dereference_check() usage"); \ > > - rcu_dereference_sparse(p, space); \ > > + /*rcu_dereference_sparse(p, space); */ \ > > ((typeof(*p) __force __kernel *)(________p1)); \ > > }) > > #define __rcu_dereference_protected(p, c, space) \ > > OK. > > One approach would be for you to replace your: > > pos = srcu_dereference((head)->next, &tomoyo_ss); > > with: > > pos = ecu_dereference_raw((head)->next); > > This will suppress the sparse complaint, but would also suppress the > lockdep complaint about using list_for_each_cookie() unprotected by an > SRCU read-side critical section. But this can be handled by placing an > appropriate RCU_LOCKDEP_WARN() in list_for_each_cookie(). > > Does that work for you? Yes, I can use below approach. Thank you. --- a/security/tomoyo/common.h +++ b/security/tomoyo/common.h @@ -1317,14 +1317,20 @@ static inline int tomoyo_round2(size_t size) #endif +static inline void tomoyo_read_lock_check(void) +{ + RCU_LOCKDEP_WARN(!srcu_read_lock_held(&tomoyo_ss), + "tomoyo_ss lock is not held."); +} + /** * list_for_each_cookie - iterate over a list with cookie. * @pos: the &struct list_head to use as a loop cursor. * @head: the head for your list. */ #define list_for_each_cookie(pos, head) \ - if (!pos) \ - pos = srcu_dereference((head)->next, &tomoyo_ss); \ - for ( ; pos != (head); pos = srcu_dereference(pos->next, &tomoyo_ss)) + for (pos = pos ? pos : rcu_dereference_raw((head)->next); \ + tomoyo_read_lock_check(), pos != (head); \ + pos = rcu_dereference_raw(pos->next)) #endif /* !defined(_SECURITY_TOMOYO_COMMON_H) */