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
| ||
|
Date: Mon, 16 Oct 2006 18:24:48 -0700 From: "Paul E. McKenney" <paulmck@...ibm.com> To: Alan Stern <stern@...land.harvard.edu> Cc: David Howells <dhowells@...hat.com>, Kernel development list <linux-kernel@...r.kernel.org> Subject: Re: Uses for memory barriers On Fri, Oct 13, 2006 at 10:27:36PM -0400, Alan Stern wrote: > On Fri, 13 Oct 2006, Paul E. McKenney wrote: > > > Ewww... How about __kfifo_get() and __kfifo_put()? These have no atomic > > operations. Ah, but they are restricted to pairs of tasks, so pairwise > > memory barriers should suffice. > > Tasks can migrate from one CPU to another, of course. But that involves > context switching and plenty of synchronization operations in the kernel, > so you're okay in that respect. Yep -- at least it had better be! Careful about how you write lightweight schedulers! ;-) > > For the pairwise memory barriers, I really like "conditionally precedes", > > which makes it very clear that the observation of order is not automatic. > > On both CPUs, and explicit memory barrier is required (with the exception > > of MMIO, where the communication is instead with an I/O device). > > > > For the single-variable case and for the single-CPU case, just plain > > "precedes" works, at least as long as you are not doing fine-grained > > timings that can allow you to observe cache lines in motion. But if > > you are doing that, you had better know what you are doing anyway. ;-) > > The reason I don't like "conditionally precedes" is because it suggests > the ordering is not automatic even in the single-CPU case. Aside from MMIO accesses, why would you be using memory barriers in the single-CPU case? If you aren't using memory barriers, then just plain "precedes" works fine -- "conditionally precedes" applies only to memory barriers acting on normal memory (again, MMIO is handled specially). So, ordering is indeed automatic in the single-CPU case. Or, more accurately, ordering -looks- -like- it is automatic in the single-CPU case. Except for MMIO -- MMIO giveth ordering in SMP and it taketh ordering away on UP. ;-) Thanx, Paul - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists