[Top] [All Lists]

Re: BUG in tcp_timer.c:tcp_retransmit_timer()

To: "David S. Miller" <davem@xxxxxxxxxx>
Subject: Re: BUG in tcp_timer.c:tcp_retransmit_timer()
From: Nagendra Singh Tomar <nagendra_tomar@xxxxxxxxxxx>
Date: Mon, 29 Mar 2004 22:54:14 +0530 (IST)
Cc: "Tomar, Nagendra" <nagendra_tomar@xxxxxxxxxxx>, <linux-net@xxxxxxxxxxxxxxx>, <netdev@xxxxxxxxxxx>
In-reply-to: <20040329200954.7baac255.davem@xxxxxxxxxx>
Organization: Adaptec
Reply-to: "Tomar, Nagendra" <nagendra_tomar@xxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
        Thats right. But what about the other cases of retransmission 
failures for which we are having a negative return (-ENOMEM, -EAGAIN, 
-EHOSTUNREACH etc). Even for these cases its not a good idea to 
artificially increment tp->retransmits, lest in some extreme case we might 
timeout a connection without a single packet going on the wire.


 On Mon, 29 Mar 2004, David S. Miller wrote:

> On Mon, 29 Mar 2004 02:39:01 +0530 (IST)
> Nagendra Singh Tomar <nagendra_tomar@xxxxxxxxxxx> wrote:
> > While reading the code of tcp_retransmit_timer(), I came across something 
> > which looks liks a BUG.
> It isn't, read below.
> > The following line 
> > 
> > if (tcp_retransmit_skb(sk, skb_peek(&sk->write_queue)) > 0)
> > 
> > should correctly read as
> > 
> > if (tcp_retransmit_skb(sk, skb_peek(&sk->write_queue)) < 0)
> Nope, it really does want greater than zero.  Less than zero
> means memory allocation error or something like that, but this is
> not what this code wants to check for.  Read the comment inside
> this code block, it says it is the code path for "local congestion"
> and the device output path indicates congestion via positive valued
> error codes.
> These codes are the NET_XMIT_* and NET_RX_* macros defined in
> linux/netdevice.h
> Thanks for the report though.


-- You have moved the mouse. Windows must be restarted for the 
   changes to take effect.

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