From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2E661C433FE for ; Sat, 19 Feb 2022 14:40:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241959AbiBSOkQ (ORCPT ); Sat, 19 Feb 2022 09:40:16 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:34620 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232726AbiBSOkP (ORCPT ); Sat, 19 Feb 2022 09:40:15 -0500 Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 95E9F7004F for ; Sat, 19 Feb 2022 06:39:56 -0800 (PST) Received: by mail-lf1-x134.google.com with SMTP id e5so10591299lfr.9 for ; Sat, 19 Feb 2022 06:39:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=references:user-agent:from:to:cc:subject:date:in-reply-to :message-id:mime-version:content-transfer-encoding; bh=rm17YSrotUSdRJ6BYuD2Ka29woyCrwxkkMypL8/+Zws=; b=R+QKwOYklID1n9atX296D0nCwG8KM3fO7//cRNML+HEH+UsM8OG1SL5DkZq0BCAUP8 2M61zfE1D2iozuGtCmbcMH3zT3/V9en3m+ZgW1MNavcyBHEFx44+uTw8a8cUS8RmKuWj qr5bhJ5U0e5HeEzivlsJDga0OFc08Pw2T+9yg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:references:user-agent:from:to:cc:subject:date :in-reply-to:message-id:mime-version:content-transfer-encoding; bh=rm17YSrotUSdRJ6BYuD2Ka29woyCrwxkkMypL8/+Zws=; b=SBcZABkqCk3AHvdMbJNWRrQm+9D3UsBzPs7CbnbSEJJO9m7B0IjOvXg/3+5k+krXGR vlZAYP+WXrdrbjyH3NcXLI9Jp/L2ejyVeY/IC8Ss67u6Yrf3ty3uBoDH59RqKvBHnOut rBkwYSm8u03Vx0UUaIE69W2cF3X7/olYiGRBhGWqmdxFPtdWpFQnV2WFLYNNIYUPdIlP p+OPlSp8VgGAdbkpcdL2Kya7CeGV9kXsVz12ZIzxMgHDto/Il+wkDl5a166eVuU+7Eag Px38TBzocmNvWDXvogmNpCEJkdfdp/42BFkwH9S4pQfifLC2w5I3Cc9wlHxgk08so1hW HAiQ== X-Gm-Message-State: AOAM532daKaAm9pCa/BCQUw8lfXfU5Gjbvyv9YoYkMqV7rujTdhHdlkg 8oXssxqUYw0TtaRawky2xmJUQw== X-Google-Smtp-Source: ABdhPJymOuYy/bNslmfXFaem6ECNBIlJebCwoNJuz6tFnhk/Bq9TuuigUhywkJVmmTV0bg2FEpbLRw== X-Received: by 2002:a05:6512:3e0a:b0:43c:8197:af34 with SMTP id i10-20020a0565123e0a00b0043c8197af34mr8338120lfv.141.1645281594928; Sat, 19 Feb 2022 06:39:54 -0800 (PST) Received: from cloudflare.com (2a01-110f-4809-d800-0000-0000-0000-0f9c.aa.ipv6.supernova.orange.pl. [2a01:110f:4809:d800::f9c]) by smtp.gmail.com with ESMTPSA id r11sm666448ljk.40.2022.02.19.06.39.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 19 Feb 2022 06:39:54 -0800 (PST) References: <20220209184333.654927-1-jakub@cloudflare.com> <20220209184333.654927-3-jakub@cloudflare.com> <87fsohea8q.fsf@cloudflare.com> User-agent: mu4e 1.6.10; emacs 27.2 From: Jakub Sitnicki To: Ilya Leoshkevich Cc: Andrii Nakryiko , bpf , Networking , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , kernel-team , Yonghong Song Subject: Re: [PATCH bpf-next v2 2/2] selftests/bpf: Cover 4-byte load from remote_port in bpf_sk_lookup Date: Sat, 19 Feb 2022 15:37:01 +0100 In-reply-to: <87fsohea8q.fsf@cloudflare.com> Message-ID: <87wnhq6htx.fsf@cloudflare.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Thu, Feb 17, 2022 at 05:11 PM +01, Jakub Sitnicki wrote: > On Thu, Feb 17, 2022 at 03:18 PM +01, Ilya Leoshkevich wrote: >> On Wed, 2022-02-16 at 13:44 -0800, Andrii Nakryiko wrote: >>> On Wed, Feb 9, 2022 at 10:43 AM Jakub Sitnicki >>> wrote: > > [...] > >>> > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /* Load from remote_port field = with zero padding (backward >>> > compatibility) */ >>> > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 val_u32 =3D *(__u32 *)&ctx->rem= ote_port; >>> > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (val_u32 !=3D bpf_htonl(bpf_= ntohs(SRC_PORT) << 16)) >>> > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 return SK_DROP; >>> > + >>>=20 >>> Jakub, can you please double check that your patch set doesn't break >>> big-endian architectures? I've noticed that our s390x test runner is >>> now failing in the sk_lookup selftest. See [0]. Also CC'ing Ilya. >> >> I agree that this looks like an endianness issue. The new check seems >> to make little sense on big-endian to me, so I would just #ifdef it >> out. > > We have a very similar check for a load from context in > progs/test_sock_fields.c, which is not causing problems: > > static __noinline bool sk_dst_port__load_word(struct bpf_sock *sk) > { > __u32 *word =3D (__u32 *)&sk->dst_port; > return word[0] =3D=3D bpf_htonl(0xcafe0000); > } > > So I think I just messed something up here. Will dig into it. Pretty sure the source of the problem here is undefined behaviour. Can't legally shift u16 by 16 bits like I did in the `bpf_ntohs(SRC_PORT) << 16` expression. Will fix.