* David Miller <davem@xxxxxxxxxxxxx> wrote: > From: Eric Dumazet <dada1@xxxxxxxxxxxxx> > Date: Tue, 28 Apr 2009 08:58:05 +0200 > > > I am not sure my day job will permit me to polish a patch mixing all > > the bits and comments. But I am glad we eventually got back spinlocks > > which are probably better than rwlocks for implementing this stuff. > > > > Instead of submitting a full patch again, we could first submit a new > > include file containg all comments and inline functions ? > > > > This include file could be local to netfilter, with a big stick on > > it to forbids its use on other areas (No changes in Documentation/ ) > > > > Then, as soon as we can go back to pure RCU solution, we can > > safely delete this controversial-locking-nesting-per-cpu-thing ? > > I say we merge Linus's locking idea into the XV patch, fixup the > commit message wording, and move on with life. > > For something that's going to get deleted as soon as the faster > grace period RCU stuff is available, it has consumed an inordinate > amount of our time :-) One more reason to factor out this code into general locking code. The latest code looks a bit similar to the old big-reader-locks hack (which got dropped for good many eons ago and with which i deny any involvement with, such as having authored it. [oh, did i say that out loud? crap.]), implemented cleanly and properly. IMHO this locking construct should be considered for linux/local_lock.h and kernel/local_lock.c. Even if the netfilter code drops its use soon afterwards ;-) [ The _only_ thing i am worried about is the apparent fact that there's so much confusion about recursion versus read-access. Recursion might be hard to factor out of the netfilter code, and maybe it's not even possible realistically (we fought years with the BKL and are still fighting it) but if its harms are not even _realized_ that difficult task turns into an impossible task ;-) ] Ingo -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
