netdev - Re: [RFC] about "net: orphan frags on receive" insanity

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]

Message-ID: <1372241543.3301.157.camel@edumazet-glaptop>
Date:	Wed, 26 Jun 2013 03:12:23 -0700
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	"Michael S. Tsirkin" <mst@...hat.com>
Cc:	netdev <netdev@...r.kernel.org>
Subject: Re: [RFC] about "net: orphan frags on receive" insanity

On Wed, 2013-06-26 at 12:56 +0300, Michael S. Tsirkin wrote:

> Please don't just revert it.

I said "revert and fix the callers"

> 
> Packets can cross e.g. the bridge and end up on the external
> interface, in which case that NIC guarantees that
> they will get transmitted eventually, so it's safe
> to transmit from guest memory, or they can end up
> in the host stack where they can stay indefinitely,
> in this case we need to orphan frags so guest networking
> can keep going.
> 
> What do you suggest exactly?
> 
> Also, I'll have to look at the generated binary - when I
> coded this up, compiler seemed to only put a
> conditional branch on the fast path, this shouldn't
> be all that expensive.

Then look again. Its 400 bytes right now.

I suggested to call this only from the impacted callers.

VM are fine, but if we slow down bare metal to close the gap, or make
appealing kernel bypass, that's not very fair.

Why normal frames received from real NIC should pay this price, I don't
know.

The conditional branch might sound not expensive, but the cache line
miss on skb_shinfo(skb)->tx_flags is expensive.

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