From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [PATCH] Fixed zero copy GSO without orphaning the fragments Date: Tue, 20 May 2014 19:16:32 +0300 Message-ID: <20140520161632.GA13942@redhat.com> References: <1400585062-13580-1-git-send-email-igorr@swortex.com> <1400596136.5367.125.camel@edumazet-glaptop2.roam.corp.google.com> <1400601938.5367.137.camel@edumazet-glaptop2.roam.corp.google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Igor Royzis , "David S. Miller" , Eric Dumazet , Tom Herbert , Daniel Borkmann , Nicolas Dichtel , Simon Horman , Joe Perches , Jiri Pirko , Florian Westphal , Paul Durrant , Thomas Graf , Jan Beulich , Herbert Xu , Miklos Szeredi , linux-kernel , netdev , Anton Nayshtut To: Eric Dumazet Return-path: Content-Disposition: inline In-Reply-To: <1400601938.5367.137.camel@edumazet-glaptop2.roam.corp.google.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org On Tue, May 20, 2014 at 09:05:38AM -0700, Eric Dumazet wrote: > On Tue, 2014-05-20 at 07:28 -0700, Eric Dumazet wrote: > > On Tue, 2014-05-20 at 14:24 +0300, Igor Royzis wrote: > > > Fix accessing GSO fragments memory (and a possible corruption therefore) after > > > reporting completion in a zero copy callback. The previous fix in the commit 1fd819ec > > > orphaned frags which eliminates zero copy advantages. The fix makes the completion > > > called after all the fragments were processed avoiding unnecessary orphaning/copying > > > from userspace. > > > > > > The GSO fragments corruption issue was observed in a typical QEMU/KVM VM setup that > > > hosts a Windows guest (since QEMU virtio-net Windows driver doesn't support GRO). > > > The fix has been verified by running the HCK OffloadLSO test. > > > > > It looks like all segments (generated by GSO segmentation) should share > original ubuf_info, and that it should be refcounted. > > A nightmare I suppose... That's what skb_frag_ref tried to do only for fragments, I guess. > (transferring the ubuf_info from original skb to last segment would be > racy, as the last segment could be freed _before_ previous ones, in case > a drop happens in qdisc layer, or packets are reordered by netem) > >