netdev - Re: [PATCH] tcp: assign the sock correctly to an outgoing SYNACK packet

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:	Mon, 08 Apr 2013 17:33:25 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	pmoore@...hat.com
Cc:	eric.dumazet@...il.com, netdev@...r.kernel.org,
	mvadkert@...hat.com, selinux@...ho.nsa.gov,
	linux-security-module@...r.kernel.org
Subject: Re: [PATCH] tcp: assign the sock correctly to an outgoing SYNACK
 packet

From: Paul Moore <pmoore@...hat.com>
Date: Mon, 08 Apr 2013 17:24:50 -0400

> If the void pointer is wrapped by a #ifdef (plenty of precedence for that) and 
> the management of that pointer is handled by LSM hooks why is it a concern?  I 
> apologize for pushing on the issue, but I'm having a hard time reconciling the 
> reason for the "no" with the comments/decisions about the regression fix; at 
> present there seems to be a level of contradiction between the two.

8 bytes times however many millions of packets per second we can process
on a big machine, you do the math.

It's memory, less cache locality, etc. etc. etc.

It's the most important data structure in the entire networking stack,
and every single byte matters.

I want the overhead to be your problem, so that only users of your
stuff eat the overhead, rather than everyone.

And don't even mention ifdefs, that's bogus, because every
distribution turns every option on, %99.9999999 of users will
therefore not see the savings.

Really, this is a dead topic, let's move on.

Thanks.
--
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