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
| ||
|
Date: Fri, 7 Mar 2014 10:41:08 -0800 From: Pravin Shelar <pshelar@...ira.com> To: Thomas Graf <tgraf@...hat.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 Fri, Mar 7, 2014 at 9:59 AM, Thomas Graf <tgraf@...hat.com> wrote: > 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. > What is problem with passing page ref with get_page() to new skb as long as it is accessed kernel? I think we should set SKBTX_DEV_ZEROCOPY flag for new skb in skb_zerocopy() to track such pages but no need call skb_orphan_frags(). > 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
Powered by blists - more mailing lists