From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: [PATCH] netfilter: use per-CPU r**ursive lock {XV}
Date: Mon, 27 Apr 2009 19:59:40 UTC
Message-ID: <fa.cvsMfjwGlUaliv65eMH/WhjKQ8o@ifi.uio.no>

On Mon, 27 Apr 2009, Stephen Hemminger wrote:
>
> All those references support my argument that the lock is being
> used recursively in this case.

What's so hard between understanding the difference between "used
recursively" and "recursive lock"?

THEY MEAN TWO TOTALLY DIFFERENT THINGS!

The fact that you don't seem to understand that is one of the things I've
been complaining about all along.

So here's a final set of clue-bat:

Clue bat #1:

 - "can be used in a recursive context" is not the same as "is recursive".

   Analogy time: Look at "strtok_r()", and the difference between that and
   "strtok()". "strtok_r()" can be used in a threaded environment. Does
   that mean that 'strtok_r()' is threaded? No. When you call
   'strtok_r()', it's still single-threaded - it's just that it _can_ be
   called in a threaded environment and then still has sane semantics.

   Now, replace "threaded" with "recursive". Do you get it?

Clue bat #2:

 - a lock that can count does not mean that it is recursive.

   Counting and recursion are TWO TOTALLY DIFFERENT ISSUES. The
   "countingness" means that there can be multiple users inside of it, and
   that, in turn, implies that maybe it can be used in a recursive
   context. But again, counting and recursion are not about the same thing
   at all.

   Put another way: a read-write lock is not a "recursive lock" despite
   the fact that you can recursively take the lock for reading. It just
   happens to count readers, and allow more than one (from _any_ context,
   not just from the "same context").

Clue bat #3:

 - A recursive lock is very much _about_ recursion. It is explicitly about
   the fact that the _same_ thread re-enters the lock, not about another
   thread being in the locked region at the same time.

   See the difference? Big, big difference. A recursive lock will lock out
   other thread contexts, even if it allows the current one to recurse.
   Notice how the _only_ thing a recursive lock allows is that recursive
   behavior, and nothing else.

   IOW, a "recursive lock" is explicitly designed for recursion. But that
   doesn't mean that recursive algorithms cannot use functions that
   aren't.

   Can you use "memcpy()" in a recursive algorithm? Yes. Does that mean
   that "memcpy()" is suddenly a "recursive memory copy"? No.

   See the difference?

Clue bat #3:

 - if you do not understand the difference between these two things, don't
   then try to claim that somebody _else_ who does understand it is
   "deluding himself".

   Analogy time: Ethernet and a modem line can both get you on the
   internet. Now, let's say that Mr Peter Paste-Eater has heard of
   ethernet, and knows you can get on the internet with an ethernet
   connection, but he happens to use a modem line to do it.

   Now, Peter Paste-Eater talks to you, and tells you he is connecting to
   the internet with ethernet, and proudly shows you his serial line and
   modem, and tells you how he uses ethernet to get onto the internet. You
   correct him, and tell him it's not ethernet.  He argues for several
   days about how he gets on the internet, and that it must thus be
   ethernet, and that you're obviously just "deluding yourself".

Now, can you see why people react badly to you talking about "recursive
locks"? You're acting like Peter Paste-Eater calling his serial line
ethernet. The fact that two _different_ things can be used for the same
end result DOES NOT MAKE THEM THE SAME THING.

In other words:

 - "Recursive locks" are different from reader-writer locks.

 - The ability to count is different from recursion, although in a lock it
   can obviously be _related_ to whether it can be used in a recursive
   environment or not. If you don't have a counter, you probably cannot
   recurse, but it's also not true that a counter implies that you always
   can.

   A traditional counting lock is the old-fasioned 'semaphore' we have,
   where the count allows for more than just simple mutual exclusion, and
   is used when you might want to allow concurrency, but need to limit it
   to some number 'n' (although, almost always, n==1)

 - What the netfilter code wants is simply not a recursive lock. It wants
   a form of locking that allows recursive _use_, but as mentioned, that
   is totally and utterly irrelevant from what we call it.

   You _could_ use a recursive lock for it. BUT NONE OF THE PATCHES THAT
   HAVE EVER BEEN POSTED HAVE BEEN RECURSIVE LOCKS! Nada. None. Zero.
   Zilch.

So don't talk about recursive locks.

Get it? Finally? Or are you going to continue to be that Paste-Eater guy
who refuses to understand that he is talking about something else than
ethernet?

			Linus

From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: [PATCH] netfilter: use per-CPU r**ursive lock {XV}
Date: Mon, 27 Apr 2009 20:00:51 UTC
Message-ID: <fa.EOabxjOQjfNaUuRz+hlbI7Nvd3k@ifi.uio.no>

On Mon, 27 Apr 2009, Linus Torvalds wrote:
>
> Clue bat #1:
>
> Clue bat #2:
>
> Clue bat #3:
>
> Clue bat #3:

Note to self: learn to count beyond three one of these days.

		Linus

From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: [PATCH] netfilter: use per-CPU r**ursive lock {XV}
Date: Mon, 27 Apr 2009 21:11:46 UTC
Message-ID: <fa.LVHzzHfMQT9hjBqobASV6jhWwAM@ifi.uio.no>

On Tue, 28 Apr 2009, Evgeniy Polyakov wrote:
>
> Just ot be sure readers will not lose the discssion topic: do you object
> against naming or realizaion?

I said _long_ ago that I thought the patch was fine.

What I object to is people mis-representing the lock, and apparently
having a really hard time admitting that having a good grounding in
networking doesn't necessarily mean that you know everything about
something as basic as locking.

> If its about the former, does 'dog's breath lock' proposed by Stephen
> fit?

Is that just an attempt to avoid admitting that they were wrong about lock
naming? And then trying to trivialize it by calling things by a
_different_ wrong name, but silly enough that they hope people won't call
them on it?

Why not just use the correct name? I think it was Mathieu that just
suggested:

	[PATCH] netfilter: use bh disabling with per-cpu read-write lock

or just call it "netfilter: use per-CPU read-write lock".

Why are people so against calling things by their correct names? Why do
certain network people seem to force a stupid and incorrect description,
when they have been told (a) that it's wrong and (b) why it's wrong
several times?

What's so hard with just doing the TechnicallyRightThing(tm) and
describing it as such?

And btw - don't get me wrong. There are _other_ ways to do that locking
too. You don't have to use a rwlock. You can do it with explicit counting,
the way Eric's original patch did. But it would be wrong to call that one
"recursive lock" too.

Or you _could_ use a recursive lock, but nobody has actually posted such
patches. It would work. No question about it. And if it actually _were_ a
recursive lock, I wouldn't have objected about the description saying it
is (although I would probably have objected to it being unnecessarily
complex, when a simpler rwlock or the explicit count thing would be
sufficient).

But since the current simple patch is using a rwlock, why not just say
that? Why call it something incorrect ("recursive lock") or nonsensical
("dog's breath lock").

As I tried to explain with an analogy, networking people would (quite
correctly) object to me calling a serial line an "ethernet cable". Why is
it so hard for netfilter people to then see why it's wrong to call a
rwlock a "recursive lock".

I mean, guys, if you don't want to read up on decades of locking work,
just google for it. Google for "recursive lock" (_with_ the quotes). At
least for me, the very first hit gives a reasonable explanation for it,
and it says:

  "POSIX allows mutexes to be recursive. That means the same thread can
   lock the same mutex twice and won't deadlock."

and realize that the "same thread" part is very much a keyword, not juat
a random implementation detail (the first answer to the question is
better than the question, but even the question at the top really does
get at the basics).

And please do realize that neither rwlocks nor the counting locks from
Dumazet's original patch do that. Never did. They simply aren't recursive
locks.

So just don't call them that. But is "dog's breath" any better? Yes, maybe
it's less _misleading_, but it sure as hell isn't any more descriptive.

			Linus