Alexey Kuznetsov <kuznet@ms2.inr.ac.ru> writes:
>
>Hello!
>> Is this right?
>
>It is right, but not quite right. TCP is pretty insensitive
>to allocated memory in xmit direction. If driver queues
>more than one or two packets, it breaks TCP not depending
>on memory commitments.
>
>UDP is really sensitive.
I analyzed the path that an skb travels through the isdn driver.
With single link ppp, the isdn_ppp might queue at most one frame
internally. The hisax isdn hardware level driver has an additional
xmit queue which is limited by 4kB payload. Thus, with MTU 1500, the isdn
internal queue length will not exceed 3-4 packets.
It was not very difficult to add passing the skb's ownership when they were
copied or cloned inside the isdn driver (at least for single link ppp).
Given the analysis above, is it worthy to commit such (skb ovnership passing)
changes or will it just complicate the driver code for very little gain?
Another question: Is the optimal txqueuelen to be configured for the
network interface somehow related to the length of the driver
internal queue?
>
>> with ppp and isdn_ppp links. (Maybe it even allows for a denial-of-service
>> exploit by sending large amounts of data through a udp socket to a
>> destination which is routed through a compressed ppp link.
>
>Do you want to say, queue size in not limited at all? 8)
I was suspecting such a bug (an unlimited queue),
but fortunatly, it turned out that I was wrong.
>Nice. It has nothing to do with socket memory accounting.
I think socket accounting will probably protect a user from filling up an
unlimited queue by accident. But exploits would still be prossibe
(e.g. by filling the queue not directly from a socket but through
another network interface such that the packets are routed through
the defective device).
Henner
-
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/