lkml.org 
[lkml]   [2009]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] netfilter: use per-cpu recursive lock (v11)


On Tue, 21 Apr 2009, Paul E. McKenney wrote:
>
> I believe that at least some of this is naming...

Maybe.

I do agree that the way netfilter would use the lock is somewhat different
from a normal 'reader-writer' lock, since this special case of readers is
about a per-cpu thing.

> So, would it help if the function names names in this patch said something
> about "local" and "global" rather than "read" and "write"?

Oh, I would have no problem at all with 'local' and 'global', in fact it
would explain _why_ that read-write lock works.

The problem with naming I have is with the 'recursive' part. There is no
ambiguity what-so-ever about what a "recursive lock" is (at least of the
traditional kind), and the lock described here is not it.

So don't get me wrong - I could certainly live with a special lock in the
networking. BUT:

- it had damn well be documented as to what it does, and why it works

- and it had better actually _work_, and not be buggy.

I suspect that using our regular reader-writer locks works well enough,
and yes, it's probably worth making it really clear that the reader
variety can only ever be used in the "local" form. That kind of is implied
by the whole function, though.

And if somebody wants to open-code it as a per-cpu spinlock and a per-cpu
'local counter', I can live with that too, but at that point I want people
to just be a lot more careful, and also document it a lot more.

Linus


\
 
 \ /
  Last update: 2009-04-21 22:29    [W:0.593 / U:0.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site