From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966822AbcKLTRj (ORCPT ); Sat, 12 Nov 2016 14:17:39 -0500 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:39017 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S966663AbcKLTRh (ORCPT ); Sat, 12 Nov 2016 14:17:37 -0500 Date: Sat, 12 Nov 2016 11:17:32 -0800 From: "Paul E. McKenney" To: Tetsuo Handa 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? Reply-To: paulmck@linux.vnet.ibm.com References: <201611092036.DAJ05243.HOOMQSVOJFFLtF@I-love.SAKURA.ne.jp> <20161109185810.GM4127@linux.vnet.ibm.com> <201611122326.GGI69239.OJLFtQVFMHOFSO@I-love.SAKURA.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201611122326.GGI69239.OJLFtQVFMHOFSO@I-love.SAKURA.ne.jp> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16111219-0008-0000-0000-00000610BA02 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00006065; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000189; SDB=6.00779917; UDB=6.00375922; IPR=6.00557310; BA=6.00004873; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00013307; XFM=3.00000011; UTC=2016-11-12 19:17:34 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16111219-0009-0000-0000-00003CF61C67 Message-Id: <20161112191732.GB4127@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-11-12_05:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1611120353 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Nov 12, 2016 at 11:26:15PM +0900, Tetsuo Handa wrote: > Paul E. McKenney wrote: > > Notwithstanding my confusion about what your self-referential > > srcu_dereference() is intended to achieve, what happens if you change the > > "void *ptr = srcu_dereference(ptr, &srcu);" to add __rcu? > > Sorry, I wrote this code for only showing warning message. > This self-referential has no intention. > > Well, you can reproduce this warning with current linux.git by running > make C=1 security/tomoyo/ with CONFIG_SECURITY_TOMOYO=y . > > security/tomoyo/common.c:896:9: error: incompatible types in comparison expression (different address spaces) > security/tomoyo/common.c:896:9: error: incompatible types in comparison expression (different address spaces) > > ---------- security/tomoyo/common.c ---------- > 896: list_for_each_cookie(head->r.acl, &tomoyo_kernel_namespace. > 897: policy_list[TOMOYO_ID_MANAGER]) { > > ---------- security/tomoyo/common.h ---------- > 1320: /** > 1321: * list_for_each_cookie - iterate over a list with cookie. > 1322: * @pos: the &struct list_head to use as a loop cursor. > 1323: * @head: the head for your list. > 1324: */ > 1325: #define list_for_each_cookie(pos, head) \ > 1326: if (!pos) \ > 1327: pos = srcu_dereference((head)->next, &tomoyo_ss); \ > 1328: for ( ; pos != (head); pos = srcu_dereference(pos->next, &tomoyo_ss)) This definition will be fun if used in an "if" statement, but I will leave that in your capable hands. > > 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? Thanx, Paul