From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759296AbaCTQCJ (ORCPT ); Thu, 20 Mar 2014 12:02:09 -0400 Received: from smtp.citrix.com ([66.165.176.89]:41480 "EHLO SMTP.CITRIX.COM" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751226AbaCTQCG (ORCPT ); Thu, 20 Mar 2014 12:02:06 -0400 X-IronPort-AV: E=Sophos;i="4.97,695,1389744000"; d="scan'208";a="113315244" Message-ID: <532B10F7.60801@citrix.com> Date: Thu, 20 Mar 2014 16:01:59 +0000 From: Zoltan Kiss User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Thomas Graf , Jesse Gross , , CC: "David S. Miller" , Pablo Neira Ayuso , Jozsef Kadlecsik , Eric Dumazet , Daniel Borkmann , Tom Herbert , Jason Wang , Florian Westphal , Joe Perches , Simon Horman , Jiri Pirko , "Michael S. Tsirkin" , Paul Durrant , Jan Beulich , Herbert Xu , Miklos Szeredi , , , , , , Subject: Re: [PATCH v2] core, nfqueue, openvswitch: Orphan frags in skb_zerocopy and handle errors References: <1395263249-16450-1-git-send-email-zoltan.kiss@citrix.com> <532ADC33.5040607@redhat.com> <532AE010.9050903@redhat.com> In-Reply-To: <532AE010.9050903@redhat.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.2.133] X-DLP: MIA1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 20/03/14 12:33, Thomas Graf wrote: > On 03/20/2014 01:16 PM, Thomas Graf wrote: >> On 03/19/2014 10:07 PM, Zoltan Kiss wrote: >>> skb_zerocopy can copy elements of the frags array between skbs, but it >>> doesn't >>> orphan them. Also, it doesn't handle errors, so this patch takes care >>> of that >>> as well. >>> >>> Signed-off-by: Zoltan Kiss >> >> Acked-by: Thomas Graf > > I take this back ;) > >>> --- >>> + if (unlikely(skb_orphan_frags(to, GFP_ATOMIC))) { >>> + skb_tx_error(to); >>> + return -ENOMEM; >>> + } > > Just noticed that you orphan the Netlink skb frags which do not > exist yet instead of the source skb frags. Oh, sorry, I'll fix this up. > >> Did you consider calling skb_tx_error() for Netlink message >> allocation failures for the upcall as well? That memory pressure >> is currently not reported back. Yeah, that makes sense, I'll fix it the callers. Btw. I guess that just provides some statistical data for the creator of the skb. At least for netback it only increment a stat counter. Zoli