netdev - Re: [net-next-2.6 PATCH 1/4] TCPCT part 1: initial SYN exchange with SYNACK data

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:	Thu, 15 Oct 2009 07:45:55 -0400
From:	William Allen Simpson <william.allen.simpson@...il.com>
To:	netdev@...r.kernel.org
Subject: Re: [net-next-2.6 PATCH 1/4] TCPCT part 1: initial SYN exchange with
 SYNACK data

David Miller wrote:
> This callback is generic and isn't designed to take opaque
> data.  All the other arguments to this callback are strongly
> typed, and this is on purpose.
> 
> You'll need to find another way to implement this.
> 
This was the most controversial change, so I made it the first separate
patch to get strong review.

#1 You recently shot down adding a GFP_ATOMIC kref (Adam's original code),
after having approved it a year ago.

#2 The entire struct could be added to all struct request_sock, but you
already rejected adding fewer bytes to the much larger tcp_sock.  And that
isn't the best strategy, as request_sock otherwise would not have a cookie
and is intended to be small.

#3 It's not possible to wrap and extend request_sock, as that is already
done by IPv6 and others, causing a conflict.  That was suggested by
another maintainer, and I drafted some code last week, but wasn't able to
figure out a non-conflicting code path.

#4 Passing a pointer parameter is the only option left that I've discovered.
Now, you've rejected that as well....

So, lead me to "another way"?
--
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