[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEkNxbETGxFAHoNDK5qEmGo+PfLxmhCniLnOTkWxpK8Ycj_r0A@mail.gmail.com>
Date: Tue, 14 Aug 2012 14:45:09 -0700
From: Bruce Curtis <brutus@...gle.com>
To: David Miller <davem@...emloft.net>
Cc: edumazet@...gle.com, netdev@...r.kernel.org
Subject: Re: [PATCH v2] net-tcp: TCP/IP stack bypass for loopback connections
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 ???
> 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.
> I hope I don't need to tell you how unacceptable this is.
>
> That also means that all of your measurements in the commit message
> weren't even made in the context where this patch will be applied.
>
> Also unacceptable.
>
I stand by my numbers!!!
> All of this makes for an extremely poor quality submission, please
> correct these issues.
Looking into Weiping's bug, can't simple use
lock_sock()/release_sock() due to A<>B locking issues (i.e.
bi-directional socket I/O).
--
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