netdev - Re: [PATCH v2] net-tcp: TCP/IP stack bypass for loopback connections

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]

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