[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20120814.145036.33234171219088031.davem@davemloft.net>
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