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  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]
Date:	Thu, 24 May 2012 00:21:49 -0300
From:	Sergio Correia <lists@...e.net>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	netdev@...r.kernel.org
Subject: Re: WARNING: at net/ipv4/tcp.c:1301 tcp_cleanup_rbuf+0x4f/0x110()

On Wed, May 23, 2012 at 3:37 PM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> 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)
>

With your patch applied, the warning hasn't shown up in the last
hours. Without it, dmesg would have been completely taken by them by
now.
I might be able to reproduce your test setup tomorrow, and if so, I will retest.

thanks,
sergio
--
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

Powered by blists - more mailing lists