Messages in this thread | | | Date | Fri, 17 Oct 2008 07:56:30 -0700 | From | "Paul E. McKenney" <> | Subject | Re: [TOMOYO #10 (linux-next) 7/8] File operation restriction part. |
| |
On Fri, Oct 17, 2008 at 05:32:43PM +0900, Kentaro Takeda wrote: > Quoting from http://lkml.org/lkml/2008/2/2/255 > > 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.
Agreed!
> 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.
Yep. You will also need the ACCESS_ONCE() on the pointer fetch in order to suppress aggressive compiler optimizations. The rcu_dereference() primitive packages them up nicely.
> 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...
Well, there are 200+ uses of rcu_dereference() for RCU, so it would 99.5%+ accurate to retain the "rcu_" prefix. ;-)
Once we have several non-RCU uses, we can probably do a much better job of coming up with a good name for the underlying independent-of-RCU primitive. So we should stick with rcu_dereference() as the name of the underlying primitive for now, and re-evaluate the naming in a year or after another five non-RCU uses of rcu_dereference() appear, whichever comes later. (My current guess for names are "pointer_subscribe()" for rcu_dereference() and "pointer_publish()" for rcu_assign_pointer(), but who knows?)
Fair enough?
> 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)?
TOMOYO can tolerate reading the complete garbage that would appear if the pointer was assigned before the pointed-to fields are initialized? I must confess that I am having a hard time believing that. Please explain how this works.
Thanx, Paul
| |