Re: [TOMOYO #10 (linux-next) 7/8] File operation restriction part.

From: Kentaro Takeda
Date: Fri Oct 17 2008 - 04:33:02 EST

Quoting from
> Similarly, the smp_read_barrier_depends() is only for initialization
> of something that is about to enter the list. As with the smp_wmb()
> primitive, smp_read_barrier_depends() also is not to protect against
> freeing. Instead, it is rcu_read_lock() and rcu_read_unlock() that
> protect against freeing.
We don't need to use rcu_read_lock() and rcu_read_unlock() because
we don't free elements in a list. I see.

However, to ensure the reader gets up-to-date value, we need to use
smp_read_barrier_depends() (which is expanded to "mb()" for SMP on
Alpha, "read_barrier_depends()" for SMP on H8300, "((void)0)" for SMP
on M68K-nommu, "((void)0)" for M68K, "do { } while (0)" otherwise)
whenever the reader fetches an element in a list.

Paul E. McKenney wrote:
> But fair enough. How about the following?
> #define worm_dereference() rcu_dereference()
> #define worm_assign_pointer() rcu_assign_pointer()
So, I understood that the rcu_dereference() and rcu_assign_pointer()
are not only for RCU. They are needed to ensure the reader gets
up-to-date value. Then, their names should be var_dereference() and
var_assign_pointer() or something, shouldn't they? The "rcu_" prefix
and comments on rcu_dereference in include/linux/rcupdate.h sound for
me that they are used for variables protected by RCU locking
mechanism only...

You are suggesting to explicitly call rcu_assign_pointer() (which
will call smp_wmb()) and rcu_dereference() (which will call
smp_read_barrier_depends()). But I think that the various cache
invalidations driven by the workload will call rcu_assign_pointer()
and rcu_dereference() sooner or later. So, if the reader can tolerate
reading non-up-to-date value (in fact, TOMOYO can), isn't there a
choice to omit rcu_assign_pointer() and rcu_dereference() (which will
cost "mb()" for SMP on Alpha)?


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at