Received: by 2002:a05:6358:701b:b0:131:369:b2a3 with SMTP id 27csp4755408rwo; Tue, 25 Jul 2023 10:24:35 -0700 (PDT) X-Google-Smtp-Source: APBJJlGmDW3tMiOmPvyCbBX1ro8+tr7jnpcmT3vdeUFWam2xdMv5o/8C+fBAqJYNY6E7zvOnrzHq X-Received: by 2002:a05:651c:22b:b0:2b7:ae29:88fd with SMTP id z11-20020a05651c022b00b002b7ae2988fdmr8920445ljn.48.1690305874733; Tue, 25 Jul 2023 10:24:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1690305874; cv=none; d=google.com; s=arc-20160816; b=WlOMFD9Q0tZW+ptKPsE0tG1CThYDvtz0o975YmZF2bwQ3fDtPL85ILqrZeS1aq8NPf 2yMprGwZzcIBD4gnmWFLa9v7hXaqPz1pT7MY02Z3zP2hyxNl6GJmIuQ1TNdOSUuktBKE ySfuM51GOBqGIDEQQ812WFKwn+hrejAVYW3r6Q4DVX2+efNExKgUwB5B0SNyVl7p0ptx p7irlcyWQrrDaQDkFOS2YfkFzDdCDYjYq+A6ijqSn/qeto3NUNKj8Z1pBr08nyNHyIde RDaq9bAejjroCBhIwTuv2rqNSm0tnTY+Q+LGAL9cdoJRufnkgBWhpn9Sll5XYzNkohCM JxwQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=gH0UOML51M3rzwv+c9agQ57fZhEB1eqJ8k22Sw4zh88=; fh=HmNbnmMp4I5RJnDp1QEnoUEC1C2DK/lIDbB+bqlabyc=; b=rVfK/z/VBP/uFg+zBsjjmbeAwH5LGOh89XA7QKQbvWEQYpO8uixQMaPxa+o9kU3bPC ksb7++ZSBKkfUU6AdiomjWcOPr1bNUDd6aYn3Ge9cm+t9Fd0yjNKb7X1j3NZIHbBH26l H01uaLKsd99/NovPbA5gvTejACt4hQ1KF1p8dIMyKrsXRkvGLOW1aZQtcYreQlC3W+Vn I9vWaryKZU5KMcy1PkNKR+x+cbp4CMOtF7BcCE5OszkPzWQTt+t4OOfkiKu478aRUbQe iE5FQezr2FNI/3bk78tjSAv5bn4rO1fK88EjU5b9CDtNeXMfBCo8lQ8KSPSBSO6c0H6I hWLg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@cloudflare.com header.s=google header.b=fvwGsJ4d; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=cloudflare.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id bi1-20020a170906a24100b009828298ddd5si8342287ejb.259.2023.07.25.10.24.07; Tue, 25 Jul 2023 10:24:34 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@cloudflare.com header.s=google header.b=fvwGsJ4d; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=cloudflare.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230104AbjGYQFZ (ORCPT + 99 others); Tue, 25 Jul 2023 12:05:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43416 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229803AbjGYQFX (ORCPT ); Tue, 25 Jul 2023 12:05:23 -0400 Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C8C9D2129 for ; Tue, 25 Jul 2023 09:05:21 -0700 (PDT) Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-5221ee899a0so4539981a12.1 for ; Tue, 25 Jul 2023 09:05:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; t=1690301120; x=1690905920; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=gH0UOML51M3rzwv+c9agQ57fZhEB1eqJ8k22Sw4zh88=; b=fvwGsJ4deZaSdRS0WEEc/DU17C9RupWojGXZqRKAIegkk3FEDs/vKLpa1le3heKqJg D0SdBtn155BDQcrjvLU1hniWPy0xji9H7b3z1e3YeKjxSrPN2B1MNE1prqJ6NuWjWhNj YbKgKEFnwxKwnlkdd+4HiQ9r2jbWFM94vNVvk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690301120; x=1690905920; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=gH0UOML51M3rzwv+c9agQ57fZhEB1eqJ8k22Sw4zh88=; b=RjcmFqhOnDk51diNeN5vzk2BqTPZbIKQ0RSFUb0hWxU0AtCFvWWcVQC3GdTuWJGvSX CUVRDW9XHfQZRlRX6/6RCE1ITSYkzHpuyHlg1PoS4zO3Owqzulq6KOCJE+zNePk+E8+R VO/2OgX7N4WOna0AwUGwK45qd9QLXqFH6VWD1YCvTNYNN4v8WRDEfJV11QgJclI/JA8t XvRryTjk6oxD1j5iIApga+WU98pXnG4d/xiTryWuyx9/lPYnmH37v/5qVj+KHusG+8lh ZIP+XhNQPVFi4G5TtMIqBKAcHQqdOaal5LVDjUlgrtLGxRW/1lpNNUw5Zv0VTUj7Ijnd byLA== X-Gm-Message-State: ABy/qLZdwft635wGgUb2tD8Aa8bnc9PCnZj1LgtXyewE4RvMe2fHS8dL I8MOs8oNQTfv7W4vdgfylJloaLXk5ozY98kSjuPxRw== X-Received: by 2002:a17:906:105d:b0:991:eb77:74e with SMTP id j29-20020a170906105d00b00991eb77074emr11339234ejj.76.1690301120091; Tue, 25 Jul 2023 09:05:20 -0700 (PDT) MIME-Version: 1.0 References: <87v8e8xsih.fsf@cloudflare.com> In-Reply-To: <87v8e8xsih.fsf@cloudflare.com> From: Yan Zhai Date: Tue, 25 Jul 2023 11:05:09 -0500 Message-ID: Subject: Re: [PATCH v3 bpf 1/2] bpf: fix skb_do_redirect return values To: Jakub Sitnicki Cc: bpf@vger.kernel.org, Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Stanislav Fomichev , Hao Luo , Jiri Olsa , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Mykola Lysenko , Shuah Khan , linux-kernel@vger.kernel.org, netdev@vger.kernel.org, linux-kselftest@vger.kernel.org, Jordan Griege , kernel-team@cloudflare.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 25, 2023 at 4:14=E2=80=AFAM Jakub Sitnicki wrote: > > On Mon, Jul 24, 2023 at 09:13 PM -07, Yan Zhai wrote: > > skb_do_redirect returns various of values: error code (negative), 0 > > (success), and some positive status code, e.g. NET_XMIT_CN, NET_RX_DROP= . > > Such code are not handled at lwt xmit hook in function ip_finish_output= 2 > > and ip6_finish_output, which can cause unexpected problems. This change > > converts the positive status code to proper error code. > > > > Suggested-by: Stanislav Fomichev > > Reported-by: Jordan Griege > > Signed-off-by: Yan Zhai > > > > --- > > v3: converts also RX side return value in addition to TX values > > v2: code style change suggested by Stanislav Fomichev > > --- > > net/core/filter.c | 12 +++++++++++- > > 1 file changed, 11 insertions(+), 1 deletion(-) > > > > diff --git a/net/core/filter.c b/net/core/filter.c > > index 06ba0e56e369..3e232ce11ca0 100644 > > --- a/net/core/filter.c > > +++ b/net/core/filter.c > > @@ -2095,7 +2095,12 @@ static const struct bpf_func_proto bpf_csum_leve= l_proto =3D { > > > > static inline int __bpf_rx_skb(struct net_device *dev, struct sk_buff = *skb) > > { > > - return dev_forward_skb_nomtu(dev, skb); > > + int ret =3D dev_forward_skb_nomtu(dev, skb); > > + > > + if (unlikely(ret > 0)) > > + return -ENETDOWN; > > + > > + return 0; > > } > > > > static inline int __bpf_rx_skb_no_mac(struct net_device *dev, > > @@ -2106,6 +2111,8 @@ static inline int __bpf_rx_skb_no_mac(struct net_= device *dev, > > if (likely(!ret)) { > > skb->dev =3D dev; > > ret =3D netif_rx(skb); > > + } else if (ret > 0) { > > + return -ENETDOWN; > > } > > > > return ret; > > @@ -2129,6 +2136,9 @@ static inline int __bpf_tx_skb(struct net_device = *dev, struct sk_buff *skb) > > ret =3D dev_queue_xmit(skb); > > dev_xmit_recursion_dec(); > > > > + if (unlikely(ret > 0)) > > + ret =3D net_xmit_errno(ret); > > + > > return ret; > > } > > net_xmit_errno maps NET_XMIT_DROP to -ENOBUFS. It would make sense to me > to map NET_RX_DROP to -ENOBUFS as well, instead of -ENETDOWN, to be > consistent. > In fact I looked at all those errno, but found none actually covers this situation completely. For the redirect ingress case, there are three reasons to fail: backlog full, dev down, and MTU issue. This won't be a problem for typical RX paths, since the error code is usually discarded by call sites of deliver_skb. But redirect ingress opens a call chain that would propagate this error to local sendmsg, which may be very confusing to troubleshoot in a complex environment (especially when backlog fills). That said I agree ENOBUF covers the most likely reason to fail (backlog). Let me change to that one in the next version if there are no new suggestions. > It looks like the Fixes tag for this should point to the change that > introduced BPF for LWT: > > Fixes: 3a0af8fd61f9 ("bpf: BPF for lightweight tunnel infrastructure") > Thanks for finding the tag. I was debating if it should be LWT commit or bpf_redirect commit: the error is not handled at LWT, but it seems actually innocent. The actual fix is the return value from the bpf redirect code. Let me incorporate both in the next one to justify better. -- Yan