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
| ||
|
Message-Id: <20100502.030321.191163013.davem@davemloft.net> Date: Sun, 02 May 2010 03:03:21 -0700 (PDT) From: David Miller <davem@...emloft.net> To: eric.dumazet@...il.com Cc: netdev@...r.kernel.org, therbert@...gle.com, hadi@...erus.ca Subject: Re: [PATCH net-next-2.6] net: eth_type_trans() should inline skb_pull() From: Eric Dumazet <eric.dumazet@...il.com> Date: Sun, 02 May 2010 08:50:32 +0200 > Excellent ! Great, here is the commit message I will use: -------------------- net: Inline skb_pull() in eth_type_trans(). In commit 6be8ac2f ("[NET]: uninline skb_pull, de-bloats a lot") we uninlined skb_pull. But in some critical paths it makes sense to inline this thing and it helps performance significantly. Create an skb_pull_inline() so that we can do this in a way that serves also as annotation. Based upon a patch by Eric Dumazet. Signed-off-by: David S. Miller <davem@...emloft.net> -------------------- > Could we assume all eth_type_trans() must call it with initial > skb->len >= (46 + 12) or not ? (According to ethernet specs, all > frames should have a minimum payload of 46 bytes) > > If not sure, maybe we should issue a WARN_ON_ONCE() > > If yes, tests could be removed and we could gain two cycles ;) Isn't the minimum ETH_ZLEN? But yes, regardless of whether the minimum ethernet frame is 58 or 60 bytes, we should require it's at least that big, and use that test consistently throughout. Anything smaller is a runt packet and should be tossed or marked as an error in some other way by the hardware. They should never make it to eth_type_trans(). -- 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