Re: [PATCH] fix race in AF_UNIX

4 messages, 3 authors, 2007-06-18 · open the first message on its own page

Re: [PATCH] fix race in AF_UNIX

From: Miklos Szeredi <miklos@szeredi.hu>
Date: 2007-06-18 09:45:14

quoted
quoted
quoted
And is anyone working on a better patch?
I have no idea.
quoted
Those patches aren't "bad" in the correctness sense.  So IMO any one
of them is better, than having that bug in there.
You're adding a very serious performance regression, which is
about as bad as the bug itself.
No, correctness always trumps performance.
To a point.  There is no black and white in this world.
quoted
Lost packets on an AF_UNIX socket are _unexceptable_, and this is
definitely not a theoretical problem.
A lot of people will consider having all of their AF_UNIX sockets on
their 64 cpu system just stop when garbage collection runs to be
unacceptable as well.
Garbage collection only ever happens, if the app is sending AF_UNIX
sockets over AF_UNIX sockets.  Which is a rather rare case.  And which
is basically why this bug went unnoticed for so long.

So my second patch only affects the performance of _exactly_ those
apps which might well be bitten by the bug itself.
Secondarily, this bug has been around for years and nobody noticed.
The world will not explode if this bug takes a few more days or
even a week to work out.  Let's do it right instead of ramming
arbitrary turds into the kernel.
Fine, but just wishing a bug to get fixed won't accomplish anything.
I've spent a fair amount of time debugging this thing, and I'm out of
ideas.  Really.  So unless somebody steps up to look at this, it won't
_ever_ get fixed.

Miklos

Re: [PATCH] fix race in AF_UNIX

From: David Miller <davem@davemloft.net>
Date: 2007-06-18 09:47:59

From: Miklos Szeredi <miklos@szeredi.hu>
Date: Mon, 18 Jun 2007 11:44:07 +0200
quoted
Secondarily, this bug has been around for years and nobody noticed.
The world will not explode if this bug takes a few more days or
even a week to work out.  Let's do it right instead of ramming
arbitrary turds into the kernel.
Fine, but just wishing a bug to get fixed won't accomplish anything.
I've spent a fair amount of time debugging this thing, and I'm out of
ideas.  Really.  So unless somebody steps up to look at this, it won't
_ever_ get fixed.
Somone just needs to find a way to only lock the socket as it is
being operated upon.

The race you are dealing with is rather simple, the queue check
and the state check need to be done atomically.  The only chore
is to find a way to make that happen in the context of what the
garbage allocator is trying to do.

I'm not even convinced that your most recent attempt is deadlock free.
Locking multiple objects the same way all at once like that is
something that needs to be seriously audited.

Re: [PATCH] fix race in AF_UNIX

From: Thomas Graf <tgraf@suug.ch>
Date: 2007-06-18 10:40:49

* Thomas Graf [off-list ref] 2007-06-18 12:32
* Miklos Szeredi [off-list ref] 2007-06-18 11:44
quoted
Garbage collection only ever happens, if the app is sending AF_UNIX
sockets over AF_UNIX sockets.  Which is a rather rare case.  And which
is basically why this bug went unnoticed for so long.

So my second patch only affects the performance of _exactly_ those
apps which might well be bitten by the bug itself.
That's not entirely the truth. It affects all applications using
AF_UNIX sockets while file descriptors are being transfered. I
agree that the performance impact is not severe on most systems
but if file descriptors are being transfered continously by just
a single application it can become rather severe.
Also think of the scenario where an application, deliberately or not,
begins a file descriptor tranfser using sendmsg() and the receiving
part never invokes recvmsg() to decrement the inflight counters
again. Every unix socket that gets closed would result in a gc call
locking all sockets.

Re: [PATCH] fix race in AF_UNIX

From: Thomas Graf <tgraf@suug.ch>
Date: 2007-06-18 11:01:29

* Miklos Szeredi [off-list ref] 2007-06-18 11:44
Garbage collection only ever happens, if the app is sending AF_UNIX
sockets over AF_UNIX sockets.  Which is a rather rare case.  And which
is basically why this bug went unnoticed for so long.

So my second patch only affects the performance of _exactly_ those
apps which might well be bitten by the bug itself.
That's not entirely the truth. It affects all applications using
AF_UNIX sockets while file descriptors are being transfered. I
agree that the performance impact is not severe on most systems
but if file descriptors are being transfered continously by just
a single application it can become rather severe.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help