[Top] [All Lists]

Re: BUG in tcp.c ?

To: kuznet@xxxxxxxxxxxxx
Subject: Re: BUG in tcp.c ?
From: Henner Eisen <eis@xxxxxxxxxxxxx>
Date: 09 Oct 2000 22:11:08 +0200
Cc: riel@xxxxxxxxxxxxxxxx, davem@xxxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: kuznet@xxxxxxxxxxxxx's message of "Sat, 7 Oct 2000 18:14:26 +0400 (MSK DST)"
References: <200010071414.SAA30580@xxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
>>>>> "kuznet" == kuznet  <kuznet@xxxxxxxxxxxxx> writes:

    kuznet> Hello!
    >> 2.2.17 is broken too.
    >> I've fixed it in my 2.2.x sources as well.

    kuznet> Dave, sendmsg cannot be used from interrupt yet.  Even in
    kuznet> 2.2 it works sometimes, but surely will crash sometimes
    kuznet> (f.e.  because of socket lock on interrupt).

I´ve used the similar trick (resetting sk->allocation to GFP_ATOMIC)
for IP/PPP tunneling over X.25 when I needed to temporarily turn
sock_alloc_send_skb() into a function callable from bh context.
However, just resetting sk->allocation is not sufficient.

In order to make sock_alloc_send_skb() non-blocking under any circumstances,
it was also necessary to set so->sndtimeo to 0. (sock_alloc_send_skb()
will never enter sock_wait_for_wmem() if timeo is 0).

nbd.c does not play the latter trick. Even if it did, tcp does not use
sock_alloc_send_skb(). And from a first look at tcp.c, it seems that
wait_for_tcp_mem() might add itsself to the wait queue even if so->sndtimeo
is 0.


<Prev in Thread] Current Thread [Next in Thread>