Re: [RFC,PATCH] RCU: clean up a few remaining synchronize_kernel() calls

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 28 Jun 2005, Paul E. McKenney wrote:

> On i386, writes are ordered.  So if CPU1 sees the callback, it is
> guaranteed to also see the data.

Yes indeed, i was certain that i missed something ;)

> However, you do have a good point -- weakly ordered CPUs would need to
> have an explicit memory barrier.  This might well already be taken care
> of by the memory barriers in the locking primitives used by the up()
> operation invoked at the end of oprofile_start(), but I did not check
> all the possible ways that these functions can be called.

I agree, that usage looks safe.

> Given that set_nmi_callback isn't invoked all that often, seems like
> it might be preferable to insert an smp_wmb() at the beginning of
> set_nmi_callback(), so that it reads as follows:
> 
> 	void set_nmi_callback(nmi_callback_t callback)
> 	{
> 		smp_wmb();
> 		nmi_callback = callback;
> 	}
> 
> Thoughts?

Andrew (rightly) tends to howls whenever someone adds a memory barrier 
without a comment ;) So if we were to make that change, how about the 
following accompanying comment;

"smp_wmb ensures that all data dependencies for the callback are posted 
and callback is ready for execution"

Thanks for elaborating, the examples certainly do help clarify usage.
	Zwane
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux