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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 14 Aug 2012 14:50:36 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	brutus@...gle.com
Cc:	edumazet@...gle.com, netdev@...r.kernel.org
Subject: Re: [PATCH v2] net-tcp: TCP/IP stack bypass for loopback
 connections

From: Bruce Curtis <brutus@...gle.com>
Date: Tue, 14 Aug 2012 14:45:09 -0700

> On Tue, Aug 14, 2012 at 2:22 PM, David Miller <davem@...emloft.net> wrote:
>>
>> Bruce, could you integrate (and unlike your submission, actually build
>> and run test) Weiping's bug fixes?
>>
>> Actually, I'm actually a little bit alarmed at Weiping's fixes,
>> because it makes it look as if you didn't test things at all under
>> net-next, as it appears that without his fixes any loopback TCP
>> connection would OOPS the kernel.
>>
> ??? rebase, build, boot a dev machine, run several hours of testing,
> take numbers from test and updated commit message (commit message test
> results changed from patch to patch submit because of this) so ???

I did it for every round of the patch series removing the entire
routing cache, so these kinds of excuses are going to fall on deaf
ears.

It's part of doing responsible development, and it's especially
critical when you are touching core parts of the kernel everyone
uses.

> 
>> In fact, it wouldn't even build without the sysctl_tcp_friends typo.
>> Indeed:
>>
>> net/ipv4/tcp.c: In function ‘tcp_recvmsg’:
>> net/ipv4/tcp.c:1935:35: error: ‘friends’ undeclared (first use in this function)
>> net/ipv4/tcp.c:1935:35: note: each undeclared identifier is reported only once for each function it appears in
>>
> Didn't build with CONFIG_NET_DMA and wasn't caught as part of
> rebase/local var name change.

'allmodconfig' builds take less than 10 minutes on current hardware,
and should be part of your patch validation.

Especially because this is the first thing I'm personally going to
do with your patch.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ