From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Abeni Subject: Re: [PATCH net-next v2 1/2] udp: msg_zerocopy Date: Mon, 26 Nov 2018 19:04:09 +0100 Message-ID: References: <20181126152939.258443-1-willemdebruijn.kernel@gmail.com> <20181126152939.258443-2-willemdebruijn.kernel@gmail.com> <11350ff03fc6b03e34f8b4acd063371c887758d8.camel@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: Network Development , David Miller , Willem de Bruijn To: Willem de Bruijn Return-path: Received: from mx1.redhat.com ([209.132.183.28]:50610 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726202AbeK0E7E (ORCPT ); Mon, 26 Nov 2018 23:59:04 -0500 In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: On Mon, 2018-11-26 at 12:59 -0500, Willem de Bruijn wrote: > The callers of this function do flush the queue of the other skbs on > error, but only after the call to sock_zerocopy_put_abort. > > sock_zerocopy_put_abort depends on total rollback to revert the > sk_zckey increment and suppress the completion notification (which > must not happen on return with error). > > I don't immediately have a fix. Need to think about this some more.. [still out of sheer ignorance] How about tacking a refcnt for the whole ip_append_data() scope, like in the tcp case? that will add an atomic op per loop (likely, hitting the cache) but will remove some code hunk in sock_zerocopy_put_abort() and sock_zerocopy_alloc(). Cheer, Paolo