netdev - Re: [PATCH] openvswitch: Orphan frags before sending to userspace via Netlink to avoid guest stall

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: <531A0911.4040304@redhat.com>
Date:	Fri, 07 Mar 2014 18:59:45 +0100
From:	Thomas Graf <tgraf@...hat.com>
To:	Pravin Shelar <pshelar@...ira.com>
CC:	Zoltan Kiss <zoltan.kiss@...rix.com>,
	Jesse Gross <jesse@...ira.com>,
	"dev@...nvswitch.org" <dev@...nvswitch.org>,
	xen-devel@...ts.xenproject.org, netdev <netdev@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] openvswitch: Orphan frags before sending to userspace
 via Netlink to avoid guest stall

On 03/07/2014 06:28 PM, Pravin Shelar wrote:
> Problem is mapping SKBTX_DEV_ZEROCOPY pages to userspace. skb_zerocopy
> is not doing that.
>
> Unless I missing something, Current netlink code can not handle
> skb-frags with zero copy. So we have to copy skb anyways and no need
> to orphan-frags here.
> If you are planning on handling skb-frags without copying then
> skb_orphan_frags should be done in netlink.

If you look at the second part of skb_zerocopy() this is exactly what
it is doing unless the target skb has sufficient linear space
preallocated. At least unless mmap is enabled in which case we would
have to copy again until we have implemented a way to pass page refs
via the nl ring buffer.

So I think Zoltan is correct in orphaning frags that come from f.e.
a tun device via zerocopy_sg_from_iovec().
--
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