Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1960042pxb; Fri, 5 Mar 2021 04:10:04 -0800 (PST) X-Google-Smtp-Source: ABdhPJzellce4nJRjub7e1XoSnf5MjGPe9Ku38VgrhcM+bHBptYMHZXcqzbfNNWutSa0IXeSRy/P X-Received: by 2002:a17:906:660b:: with SMTP id b11mr2092402ejp.458.1614946204447; Fri, 05 Mar 2021 04:10:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614946204; cv=none; d=google.com; s=arc-20160816; b=L9YV1pjl3gp0MuoE+uxPoEAkW1o3dKvhP2vzFhwHEzzWkEEtY8uYSBrZ7V/7g8/RbJ FfIaC1W1wsyy1Ut3KYR2HWRMW75sGCl9M9WJ9sviuhheAxO8P58WgktbB7M8SN4jI4h5 ntggAICPKtHxS4FGElFQqOpU56uOA8kPQZeTwfuETZYFceRbasKAURGRyjaUpnZsVnqI 4YWHMd/rtrTj/FPPPWjY7ZIMDt3ZZrvJ0kCJDTYimpV/wNGcD5EzDBbMnYcsI+F/SR47 u0JugyOMdPqa6ynoDssmIpxkNScKtHQDsxRfzG/wfTSup36WrpnGyygRFfot/5kOXyGL T8xQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=0T4sYjk3wRZzjG/QHAIvuP6rKIH4m6dqz5ONCAsok4U=; b=AtULkniXOXFTsl1e1SGwwV20LT8SwT2Ej14mIgq1x50+5m9eO/hsBfMceVhYHaqVr6 uyR5pc1Q0Dbe7z5qUzxa84XfqWHkNZiAlLbvX7o2HrP3dQq4X1yhvEP02/8i9VEZteGx De+9Wf3p672eXSr1HAtInbJ1G9zcpxWw57UXU7KCq1wo6ZFwhp7iLE6KfwRQDygWNmMh fO8RYRvoHNmArLm/kDmFIa7RJgZLlwzyzL2PC+qhu+msXWF6MnoQTGzDCK6789mNGIqd 7KeNraTZ50QueEbo6lNds6QhMkah8MrMUs4FMGl5M7XcH4oYd42v8bRvDBtIVybJzxpf J7AA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=X9aYOJ2Q; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h13si1363967edq.173.2021.03.05.04.09.30; Fri, 05 Mar 2021 04:10:04 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=X9aYOJ2Q; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229813AbhCEMI2 (ORCPT + 99 others); Fri, 5 Mar 2021 07:08:28 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60484 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229493AbhCEMH6 (ORCPT ); Fri, 5 Mar 2021 07:07:58 -0500 Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B5FE1C061574; Fri, 5 Mar 2021 04:07:58 -0800 (PST) Received: by mail-pf1-x436.google.com with SMTP id 18so1981995pfo.6; Fri, 05 Mar 2021 04:07:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0T4sYjk3wRZzjG/QHAIvuP6rKIH4m6dqz5ONCAsok4U=; b=X9aYOJ2QUP2xz10GjaNI2tVnTar2w3YTbJkB56nhZ43TCzh4a0g4Kb7e8XS9lECzRG 5BaePC2mMQk+/MQRKX0PGp2vpm3tkiA22y8AwJYIjs3X5Cb4tNKARktq6vkbAHcZpEGN Yzk5DU2q50UwaF4xlEagNR7sQDl2vsDpaI8MGk1LmIkxSUhGnzkBfiJdIPSD9YjZnyNa z1YfGjVkMVdCuwArFbDgpglD2TbV+2yMdfo6kvoEVGfKh5rKlrEnJMFxbOfCvicuiisY RNMr4au0QQrZJcaf6eXQcZQnCjd/vxDr+cnEu0ELaz6rMPx2rCf8B1ya358Qg+QSuTmv x0iQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0T4sYjk3wRZzjG/QHAIvuP6rKIH4m6dqz5ONCAsok4U=; b=TCto31YS7EouOtTyaWmRb/iuEU2nWAU08BaO+DE+yXb0BRGAyn2CippMV51mMot/sO kDEZvJONg/qwXLJZHCE4P/Cv95X8qIyyr0Aag8vHveDE4BdzqBn3Sq4RdUMAsXTTSS0j 64oM9NcP0s9BgPqi+RJPu6wmyPyLwZPiw2oX381zFoaxNoxa/AbyjvkFJKvRDqiNLQxc YloSSxnECuVXcMtPReDHt92qByZCWwBZw7WjrZXMygX8/h46zqV4y6u3l4fW2Fj8+qVp dGs0sWCIeOyu7dlG5h3FYkb81YDlIOasebj8LvrC21oTpmDuDuRnh78ypy//LAUqya1t d6tQ== X-Gm-Message-State: AOAM530CDL6FJxKh+8Vk/FQNKaSZFbkf2pg2fXjtutmqUcNu/wIrDJCq WkmzaJqI7eKHhFpF6Ix1R+9UGZ5e26nqxgmwk3I= X-Received: by 2002:a63:1906:: with SMTP id z6mr8464802pgl.292.1614946078278; Fri, 05 Mar 2021 04:07:58 -0800 (PST) MIME-Version: 1.0 References: <20210305092534.13121-1-baijiaju1990@gmail.com> In-Reply-To: <20210305092534.13121-1-baijiaju1990@gmail.com> From: Magnus Karlsson Date: Fri, 5 Mar 2021 13:07:47 +0100 Message-ID: Subject: Re: [PATCH] net: xdp: fix error return code of xsk_generic_xmit() To: Jia-Ju Bai Cc: =?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= , "Karlsson, Magnus" , Jonathan Lemon , "David S. Miller" , Jakub Kicinski , Alexei Starovoitov , Daniel Borkmann , Jesper Dangaard Brouer , John Fastabend , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , KP Singh , Network Development , bpf , open list Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Mar 5, 2021 at 10:28 AM Jia-Ju Bai wrote: > > When err is zero but xskq_prod_reserve() fails, no error return code of > xsk_generic_xmit() is assigned. > To fix this bug, err is assigned with the return value of > xskq_prod_reserve(), and then err is checked. This error is ignored by design. This so that the zero-copy path and the copy/skb path will return the same value (success in this case) when the completion ring does not have a spare entry we can put the future completion in. The problem lies with the zero-copy path that is asynchronous, in contrast to the skb path that is synchronous. The zero-copy path cannot return an error when this happens as this reservation in the completion ring is performed by the driver that might concurrently run on another core without any way to feed this back to the syscall that does not wait for the driver to execute in any case. Introducing a return value for this condition right now for the skb case, might break existing applications. Though it would be really good if you could submit a small patch to bpf-next that adds a comment explaining this to avoid any future confusion. Something along the lines of: /* The error code of xskq_prod_reserve is ignored so that skb mode will mimic the same behavior as zero-copy mode that does not signal an error in this case as it cannot. */. You could put it right after the if statement. Thank you: Magnus > The spinlock is only used to protect the call to xskq_prod_reserve(). > > Reported-by: TOTE Robot > Signed-off-by: Jia-Ju Bai > --- > net/xdp/xsk.c | 8 +++++++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c > index 4faabd1ecfd1..f1c1db07dd07 100644 > --- a/net/xdp/xsk.c > +++ b/net/xdp/xsk.c > @@ -484,8 +484,14 @@ static int xsk_generic_xmit(struct sock *sk) > * if there is space in it. This avoids having to implement > * any buffering in the Tx path. > */ > + if (unlikely(err)) { > + kfree_skb(skb); > + goto out; > + } > + > spin_lock_irqsave(&xs->pool->cq_lock, flags); > - if (unlikely(err) || xskq_prod_reserve(xs->pool->cq)) { > + err = xskq_prod_reserve(xs->pool->cq); > + if (unlikely(err)) { > spin_unlock_irqrestore(&xs->pool->cq_lock, flags); > kfree_skb(skb); > goto out; > -- > 2.17.1 >