Greg KH wrote: > RCU is lockless-on-reading from what I remember. I vaguely remembered that there was an issue with RCU that made that not quite true. My thanks to someone else who emailed me and reminded me of at least one issue: kernel preemption. RCU isn't lockless if kernel preemption is enabled. See the source code in: http://lxr.linux.no/source/include/linux/rcupdate.h?v=2.6.8.1#L136 for lines 136-137, and then: http://lxr.linux.no/source/include/linux/preempt.h?v=2.6.8.1#L28 and friends. (Yes, I know 2.6.9 is out there; this is just an easy way for me to provide a hypertext link to a specific line of code). Without pre-emption, it's a no-op; with pre-emption, there's both a count change and a barrier operation on both the lock & unlock of the read lock. That's true of 2.6.0 as well; I believe that came in for version 2.5.4-pre6 (http://www.linuxdevices.com/news/NS3989618385.html). Yes, currently many distributions don't turn on pre-emption by default, but the low-latency benefits of preemption are nice. I think it's worth thinking about an even more lockless version of invoking each module & getting any relevant security blobs. I believe you can do that with some pointer fiddling and careful alignment; my old draft made it possible to do lockless module chaining, without locking even in the presence of preemption. I could be mistaken; these newer stackers are trying to do things that mine wasn't trying to do. But it's worth thinking about. --- David A. Wheeler
This archive was generated by hypermail 2.1.3 : Mon Dec 20 2004 - 15:33:12 PST