netdev - Re: WARNING: at net/ipv4/tcp.c:1301 tcp_cleanup

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1337798274.3361.3234.camel@edumazet-glaptop>
Date:	Wed, 23 May 2012 20:37:54 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Sergio Correia <lists@...e.net>
Cc:	netdev@...r.kernel.org
Subject: Re: WARNING: at net/ipv4/tcp.c:1301 tcp_cleanup_rbuf+0x4f/0x110()

On Wed, 2012-05-23 at 15:30 -0300, Sergio Correia wrote:
> On Wed, May 23, 2012 at 1:36 PM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> > On Wed, 2012-05-23 at 12:56 -0300, Sergio Correia wrote:
> >> On Wed, May 23, 2012 at 12:08 PM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> >> > On Tue, 2012-05-22 at 11:47 -0300, Sergio Correia wrote:
> >> >> Hi Eric,
> >> > ...
> >> >> Yes, it's an Atheros AR9285 adapter.
> >> >> This morning I did a make mrproper before rebuilding the kernel
> >> >> (should I always do that?), but the warning has just appeared again.
> >> >
> >> > OK, I am taking a look at this problem, thanks.
> >> >
> >>
> >> Thanks. Let me know if you need additional info. As of now, my dmesg
> >> basically shows only those warnings.
> >
> > I believe I found the bug and am testing a fix right now.
> >
> > By the way, we might have the same problem in tcp collapses.
> >
> > TCP coalescing (introduced in linux-3.5) triggers the problem faster.
> >
> > Please test following patch :
> >
> 
> I reverted back to 471368557a734c6c486ee757952c902b36e7fd01 and it
> took almost one hour to trigger the warning. Now I have applied your
> patch and will report back how it went after a few hours of testing.

Thanks

I triggered it very fast in my lab using following setup

Sender machine :

# tc qdisc add dev eth0 root netem delay 1ms 3ms 20 reorder 10 20
for i in `seq 1 8`
do
  netperf -t OMNI  -C -c -H 172.30.42.8 -l 60 &
done
wait
# tc -s -d qd
qdisc netem 8002: dev eth0 root refcnt 2 limit 1000 delay 1.0ms  3.0ms
20% reorder 10% 20% gap 1
 Sent 66030032010 bytes 43992779 pkt (dropped 13846, overlimits 0
requeues 2712184) 
 backlog 0b 0p requeues 2712184 

receiver machine runs a netserver and triggers the bug in few seconds.

(receiver being a slow machine, with r8169 NIC)



--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html