linux-kernel - Re: [srcu] Can we suppress sparse warning?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20161112191732.GB4127@linux.vnet.ibm.com>
Date:   Sat, 12 Nov 2016 11:17:32 -0800
From:   "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:     Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
Cc:     josh@...htriplett.org, rostedt@...dmis.org,
        mathieu.desnoyers@...icios.com, jiangshanlai@...il.com,
        linux-kernel@...r.kernel.org
Subject: Re: [srcu] Can we suppress sparse warning?

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