netdev
[Top] [All Lists]

Re: BUG in tcp.c ?

To: Henner Eisen <eis@xxxxxxxxxxxxx>
Subject: Re: BUG in tcp.c ?
From: Rik van Riel <riel@xxxxxxxxxxxxxxxx>
Date: Mon, 9 Oct 2000 17:38:40 -0300 (BRST)
Cc: kuznet@xxxxxxxxxxxxx, davem@xxxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <oud7h9kc6b.fsf@xxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
On 9 Oct 2000, Henner Eisen wrote:
> >>>>> "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.

Hmmm, so we will need some surgery in the TCP (and IP?) code
to make swap-over-network a reality ? 

If it /should/ be ok (according to the network folks), I'll
probably dig in and try to fix it, but if it will take some
deep surgery, I'll probably wait until I've fixed some other,
more urgent, VM issues ...

regards,

Rik
--
"What you're running that piece of shit Gnome?!?!"
       -- Miguel de Icaza, UKUUG 2000

http://www.conectiva.com/               http://www.surriel.com/


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