> >I see... but what to do then? We did not remove syn skb and not yet
>
> What do you mean with "what to do then"?
>
> Excuse but my bad English is hurting my understanding again.
It is my bad English. I wanted to say, that I understood the problem,
dazed, confused and have to think.
Next my mail and mail from Al explains more.
The situation is really weird. The problem of wrong resource
accounting on unix sockets is well-known flaw, but I understood
that it is fatal only now.
F.e. the simplest example is datagram socket. We account for
sent skbs on sender. I considered it as security problem, f.e.
client asks keyserver, server replies but client does not read reply.
Then client repeats this until sndbuf of keyserv overflows.
Finita: keyserver is blocked forever.
But I missed even worse thing: this guy could make:
for(;;) {
s = socket(PF_UNIX, SOCK_DGRAM, 0);
sendto(s, some service, its sndbuf);
close(s);
}
Essentially, operation of connect on SOCK_STREAM is equivalent.
It means, that solution is either moving flow control to receiver side
or keeping queues on sender side. It is final solution,
but it requires serious rewrite of af_unix.c.
We did not it at the beginning of 2.1, when the problem was understood,
and it is too late to make it now. In fact, it was the reason,
why af_netlink was written from scratch: it uses receiver based flow control.
What can we make now?
The first guess is to limit total number of unix
sockets (both alive and dead) to max_files/2.
Then one process still may eat all of them. I still have no answer.
With stream sockets we could kill orderly release semantics
and to purge data on close, with some ugly fixes in select(),accept()
to avoid random blocking. Hmm... it is not clear, how missing
orderly release will affect apps. connect(),write(),close() is really used
sometimes. And it does not solve problem with datagram sockets.
Well, let's not fall to panic yet 8) I do not remember cases, when
thinking did help 8)
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/