On Wed, Jan 05, 2011 at 01:12:33PM +0100, Marek Lindner wrote:
Hi Linus,
great that you embraced the feedback that quickly. As discussed in Berlin I'll go through your patches once I have a little bit more room to manoeuvre (next week is rather packed).
Would be great if someone could check the usage of rcu-locking + refcounting. I was also a little confused because in "Documentation/RCU/listRCU.txt" list_del_rcu() and list_add_rcu() are not protected with a spinlock for the list here, but in the batman-adv code we are usually having those extra locks. Do I have to leave those spinlocks or can I remove them for adding/deleting entries in the neigh_list?
I don't understand why you think there are no locks. Did you read the text around the examples (Documentation/RCU/listRCU.txt) ? I mean, below the first example (which indeed does not contain spinlocks) it is written:
Normally, the write_lock() and write_unlock() would be replaced by a spin_lock() and a spin_unlock(), but in this case, all callers hold audit_netlink_sem, so no additional locking is required. The auditsc_lock can therefore be eliminated, since use of RCU eliminates the need for writers to exclude readers. Normally, the write_lock() calls would be converted into spin_lock() calls.
If you check the following example you'll find spinlocks or search for list_del_rcu() in the kernel sources to find more usage scenarios.
Regards, Marek
Oki doki, thanks. I was a little confused by the example at that section and couldn't find any other references to "audit_netlink_sem" (though it is/was probably just a common semaphore, I guess). Ok, quick searching of list_del_rcu() in the kernel code (via http://lxr.linux.no/linux) cleared things up.
Cheers, Linus