On Thu, 25 Jul 2002 Valdis.Kletnieksat_private wrote: > Personally, I'd worry more about cache coherency issues - there are 4 > important points in a 'store to memory' operation: > > 1) When CPU 1 sends the word to L1/L2 cache > 2) When CPU 1's cache controller flushes the cache line to main memory. > 3) When CPU 2 notices the line it already has in L1/L2 cache is invalid > 4) When CPU 2 actually loads a valid cache line from main memory > > (Yes, I know 3 and 4 are "logically" the same time from CPU 2's point of view - > but Murphy guarantees that if CPUs 1 and 2 are running code that's in a race, > CPU 3 will be in that code TOO (think multiple CPU's all waiting on the same > spinlock), and will be doing its best to create another race between (3) and > (4)). > The use of the spinlock protects against memory ordering issues for writing and testing the security_ops pointer. The pointer can only be set under the lock, and any outstanding memory writes are forced during spinlock release. Upon subsequent entry to the critical region, a read of the pointer value will thus return the correct value. > At least on the S/390 from IBM, the architecture specifically states that > other CPUs may not actually see a store to memory happen for an *indefinite* > amount of time - until a serialization event happens (if you've ever had to > code 'bcr 15,0' on an IBM, you know what I mean). > Indeed, the S/390 spinlock release code contains 'bcr 15,0'. - James -- James Morris <jmorrisat_private> _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Thu Jul 25 2002 - 05:53:58 PDT