Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp5100976pxb; Wed, 26 Jan 2022 04:58:30 -0800 (PST) X-Google-Smtp-Source: ABdhPJxyImMzDVxZT4DLVl4iHpAM26zzYgQqZMxE77tZbR/cXg8mfNqxvi0UQjVID+hg39VAiBpF X-Received: by 2002:a17:907:7f05:: with SMTP id qf5mr12451681ejc.241.1643201910428; Wed, 26 Jan 2022 04:58:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643201910; cv=none; d=google.com; s=arc-20160816; b=KPCAoDpwLP5gAo/Fj/2tCt95Ezi5bumufnlbMTPi6thHag2AMZwZcnspKDE7z7PMYN ZrPfU8UWBNZJgMzvuJMmdRguc4UHvDhflY2VTmIzztxBahD13tgculX/+KBsUo34sb1Y m2qfRc48JtPZmO11hnaQ5R0hs65KmJv7fpNuqjGcTvuTjRY++AMawGpKU6h8EyLar1b9 Q54wntSqebXE4zGaiq4k69283V4ZG7+TjXgTgVmJ8Exzz9yAyDDKMFEYjsUiiTjMCBpD sQguOXbEg3y5ACkN/gK8f0Iaxr1kGBq2HYeUcbC0V1oeQ/KhyvkDuxnPkiYw2Ff67fmE EXEQ== 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=EBImikir9ryAT25BALwOBZaIdeZpyfkOerp8AGfow0Y=; b=KRDN2BiCErIsyqtnzB322C6b7qqXjGkP6tX9BWnzVfQ7rXuW015WVzRAEBbjnpoNvz sRD4kFf8YUnx935Ow1pLcOwHKO3/dCsvHnMhmb54I218OGikdWb5pUlZtzLQzyrpiqgM ZmP1+7gAMLgaIqbslD8mwTP674Di47w64TiZbILuvFTcs5Fe8Yhltwz4a4ZpCEv756oY nrtc1KIEf8LpDybjkPkWwnhrA24HC5K5U7cHFqPD3P03ZMsv7BkyQ6t+vj1eUfYlPSld iWSYFsLz98HWrUxZjC1pB/MlyNuZGFaVxVcm/Hn3QONswLmYlYvQg+otVnVd2PvgiknO Pt8A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b="nS/qs9Ks"; 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 he40si3372777ejc.403.2022.01.26.04.58.05; Wed, 26 Jan 2022 04:58:30 -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=20210112 header.b="nS/qs9Ks"; 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 S234631AbiAYXDG (ORCPT + 99 others); Tue, 25 Jan 2022 18:03:06 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43694 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234586AbiAYXCt (ORCPT ); Tue, 25 Jan 2022 18:02:49 -0500 Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 09A59C06173B; Tue, 25 Jan 2022 15:02:49 -0800 (PST) Received: by mail-pl1-x635.google.com with SMTP id u11so20779936plh.13; Tue, 25 Jan 2022 15:02:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EBImikir9ryAT25BALwOBZaIdeZpyfkOerp8AGfow0Y=; b=nS/qs9KssIJBTLzoLDLJszdVUiXxpkn92Gj/mSrQkvnuM5mgW1SQgyG1o+8jAruIj7 ECS09HKz/+dnA+KNFP2GgHqKwmKO2hCXnqNDrNrDNuKMBTs+5Z+l4C0tk/fZMCZnoZdr YhC3VN2lfAFgR/0mdLfFIUG4PJRoh7kFfMHP3pqhfdEsCUT78J5zjm1dWL8MFMZ8d0pX WuURUQf53/4jtwjRwdI9Dxw5Y8rZR7KHJRXKizykEq7xkNycQK5bwgeSMYMBj17IFW+r mblklustS3N81EEQYEu675+sO1LupmJjWR4M2HVHsEYGXegfUO32PGTktkreTBVB37VZ +OQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EBImikir9ryAT25BALwOBZaIdeZpyfkOerp8AGfow0Y=; b=okBwUwq6UTYsMQhAX2djnD4sxagRhUPIwoCkT0VIwEdcvYeTlD2gCJnj4Siz13NK06 ikN9705PjjPrDXmaaQo/qytClKv4VNB3y2D52PviZqS4xAyWSzuNQRt5V8QQvKnjeIWy Z6+pbf1d1gRUwL0wmtWidM5eZUk7OW5F7OxS+o4W/746PSBudOJAnH1tjfz6PEiuxNoI Ed2Gv5ccH2HNOmpPFLnGGXdXnFpQqsmFObgFjWA0SDzghyu6IxD9hf+6WxCTGiVqrc1I XLKsU+X+rAiPMtX2CylA+1YZtf0OSyCtMAJ8yljYS+UL+9sakvB+8je+cinTtTSzleZw 6a/g== X-Gm-Message-State: AOAM532xm9DnCjwiERDDxWlvOIyKrtLILdU+CGmUNqUajIyuLcHhKXfN bFBjG5yLO0k+F7T+g0Bqt0q3J3Dboak4wq1tuoU= X-Received: by 2002:a17:90b:3b4c:: with SMTP id ot12mr5749610pjb.62.1643151768394; Tue, 25 Jan 2022 15:02:48 -0800 (PST) MIME-Version: 1.0 References: <20220113070245.791577-1-imagedong@tencent.com> <87sftbobys.fsf@cloudflare.com> <20220125224524.fkodqvknsluihw74@kafai-mbp.dhcp.thefacebook.com> In-Reply-To: <20220125224524.fkodqvknsluihw74@kafai-mbp.dhcp.thefacebook.com> From: Alexei Starovoitov Date: Tue, 25 Jan 2022 15:02:37 -0800 Message-ID: Subject: Re: [PATCH bpf-next] bpf: Add document for 'dst_port' of 'struct bpf_sock' To: Martin KaFai Lau Cc: Jakub Sitnicki , Menglong Dong , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Song Liu , Yonghong Song , John Fastabend , KP Singh , Network Development , bpf , LKML , Mengen Sun , flyingpeng@tencent.com, mungerjiang@tencent.com, Menglong Dong Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 25, 2022 at 2:45 PM Martin KaFai Lau wrote: > > On Tue, Jan 25, 2022 at 08:24:27PM +0100, Jakub Sitnicki wrote: > > > diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h > > > index b0383d371b9a..891a182a749a 100644 > > > --- a/include/uapi/linux/bpf.h > > > +++ b/include/uapi/linux/bpf.h > > > @@ -5500,7 +5500,11 @@ struct bpf_sock { > > > __u32 src_ip4; > > > __u32 src_ip6[4]; > > > __u32 src_port; /* host byte order */ > > > - __u32 dst_port; /* network byte order */ > > > + __u32 dst_port; /* low 16-bits are in network byte order, > > > + * and high 16-bits are filled by 0. > > > + * So the real port in host byte order is > > > + * bpf_ntohs((__u16)dst_port). > > > + */ > > > __u32 dst_ip4; > > > __u32 dst_ip6[4]; > > > __u32 state; > > > > I'm probably missing something obvious, but is there anything stopping > > us from splitting the field, so that dst_ports is 16-bit wide? > > > > I gave a quick check to the change below and it seems to pass verifier > > checks and sock_field tests. > > > > IDK, just an idea. Didn't give it a deeper thought. > > > > --8<-- > > > > diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h > > index 4a2f7041ebae..344d62ccafba 100644 > > --- a/include/uapi/linux/bpf.h > > +++ b/include/uapi/linux/bpf.h > > @@ -5574,7 +5574,8 @@ struct bpf_sock { > > __u32 src_ip4; > > __u32 src_ip6[4]; > > __u32 src_port; /* host byte order */ > > - __u32 dst_port; /* network byte order */ > > + __u16 unused; > > + __u16 dst_port; /* network byte order */ > This will break the existing bpf prog. I think Jakub's idea is partially expressed: + case offsetof(struct bpf_sock, dst_port): + bpf_ctx_record_field_size(info, sizeof(__u16)); + return bpf_ctx_narrow_access_ok(off, size, sizeof(__u16)); Either 'unused' needs to be after dst_port or bpf_sock_is_valid_access() needs to allow offset at 'unused' and at 'dst_port'. And allow u32 access though the size is actually u16. Then the existing bpf progs (without recompiling) should work?