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 X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D840BC43381 for ; Tue, 26 Feb 2019 01:30:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9997C217F4 for ; Tue, 26 Feb 2019 01:30:30 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=fb.com header.i=@fb.com header.b="FNTXS0XW"; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.i=@fb.onmicrosoft.com header.b="OzjSFt32" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726082AbfBZBa3 (ORCPT ); Mon, 25 Feb 2019 20:30:29 -0500 Received: from mx0a-00082601.pphosted.com ([67.231.145.42]:56392 "EHLO mx0a-00082601.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725842AbfBZBa2 (ORCPT ); Mon, 25 Feb 2019 20:30:28 -0500 Received: from pps.filterd (m0044008.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x1Q1Pk45022943; Mon, 25 Feb 2019 17:30:08 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=facebook; bh=WXeN8g+tYgCg1k50Wr7riHsmW0XJRjqEK1HuxUS6A4Q=; b=FNTXS0XW2EJWx8KbmwAdyN8B1DjZOJf50s+LWlSznWjWu48UMgED3twQvKFJV4Vivd0m PtO04T4gD27hSL8fArfDv9XC5Lyr2I4isBT61o7387L0zpS8bIA2XopSFOlZjmxqRvUK 5YXkVbcGX6oWHzj9SGxCJxb/RUqA9ilPzPU= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2qvsk98djq-5 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 25 Feb 2019 17:30:08 -0800 Received: from frc-mbx04.TheFacebook.com (192.168.155.19) by frc-hub06.TheFacebook.com (192.168.177.76) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3; Mon, 25 Feb 2019 17:30:05 -0800 Received: from frc-hub03.TheFacebook.com (192.168.177.73) by frc-mbx04.TheFacebook.com (192.168.155.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3; Mon, 25 Feb 2019 17:30:05 -0800 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.73) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3 via Frontend Transport; Mon, 25 Feb 2019 17:30:05 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WXeN8g+tYgCg1k50Wr7riHsmW0XJRjqEK1HuxUS6A4Q=; b=OzjSFt329bG3oCc+lSbLe/kmk62FV0Z37v2E0Dya3YKJtTgPfOWj7wol+K01yCSIWmzrg7ma1g3GmGQYdw8FVNuB5MrAEuhL2RTDr4DrX+WNO6lpEdCndt44xrYPUfGu05ZU1FWA78OgwsxoD6KwuiPB+bLfZrKmu91qf8ruf8w= Received: from MWHPR15MB1790.namprd15.prod.outlook.com (10.174.255.19) by MWHPR15MB1886.namprd15.prod.outlook.com (10.174.100.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.16; Tue, 26 Feb 2019 01:30:03 +0000 Received: from MWHPR15MB1790.namprd15.prod.outlook.com ([fe80::ac2f:bf87:54e:48a2]) by MWHPR15MB1790.namprd15.prod.outlook.com ([fe80::ac2f:bf87:54e:48a2%12]) with mapi id 15.20.1643.019; Tue, 26 Feb 2019 01:30:03 +0000 From: Martin Lau To: Stanislav Fomichev CC: Lawrence Brakmo , netdev , "Alexei Starovoitov" , Daniel Borkmann , "Eric Dumazet" , Kernel Team Subject: Re: [PATCH v2 bpf-next 2/9] bpf: Add bpf helper bpf_tcp_enter_cwr Thread-Topic: [PATCH v2 bpf-next 2/9] bpf: Add bpf helper bpf_tcp_enter_cwr Thread-Index: AQHUyxQyHg2G+7UO40qzQN9osxozBaXxKZkAgAAl0YA= Date: Tue, 26 Feb 2019 01:30:02 +0000 Message-ID: <20190226012959.4gttysrj3khqumc5@kafai-mbp.dhcp.thefacebook.com> References: <20190223010703.678070-1-brakmo@fb.com> <20190223010703.678070-3-brakmo@fb.com> <20190225231438.GC32115@mini-arch> In-Reply-To: <20190225231438.GC32115@mini-arch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: BYAPR07CA0058.namprd07.prod.outlook.com (2603:10b6:a03:60::35) To MWHPR15MB1790.namprd15.prod.outlook.com (2603:10b6:301:4e::19) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2620:10d:c090:200::9f57] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: eb5f5fd2-c287-4158-9df5-08d69b89eddc x-microsoft-antispam: BCL:0;PCL:0;RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020);SRVR:MWHPR15MB1886; x-ms-traffictypediagnostic: MWHPR15MB1886: x-microsoft-exchange-diagnostics: 1;MWHPR15MB1886;20:XBzK6feC4quslFuNCyk2iumRhw6VdZOwHT0IkyhAfNcX6KK07SLZ3ca1nl6DD74fXwwHNineDOaXVOVW64UGjuIjafPnGc2JshKZlIeGuqUFXY8aTmSllAL1yAH5mbUFEou16FVZaetPuS4dKUjBOo2W1KOrEKzw6x7yXNx17U8= x-microsoft-antispam-prvs: x-forefront-prvs: 096029FF66 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(366004)(199004)(189003)(498600001)(97736004)(25786009)(5660300002)(8936002)(1076003)(68736007)(256004)(14454004)(186003)(6916009)(6486002)(5024004)(4326008)(229853002)(6246003)(71190400001)(71200400001)(6436002)(53936002)(106356001)(7736002)(105586002)(54906003)(76176011)(52116002)(81156014)(81166006)(102836004)(8676002)(6116002)(99286004)(386003)(6506007)(46003)(446003)(476003)(11346002)(2906002)(86362001)(305945005)(486006)(6512007)(9686003);DIR:OUT;SFP:1102;SCL:1;SRVR:MWHPR15MB1886;H:MWHPR15MB1790.namprd15.prod.outlook.com;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;A:1;MX:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 6E5oLfEOwsaxVzPyJVtWRdbi0mMiM+26E0dPw8N19s1kHyLSArNGu0Hu0g84jEngfGcHMKQVIooWpa4Y1iXFg14V933W9cZsFb97Z6Usk7IIexC3d7sNsT6uedz0pyLHIowmjOP/0nFKryOCFz287HCze3vRkkspTstoGwod6zcYuSV9e0G7gBVQ7McIW3203A1rDbT04lXkZKoTEMAsQXnqp39X+TZEJY/WAh/xo/0hYjoNU6gBgbWrL73xTLTJca6deDBaAidW6OYtMCjfwp/WXNQplOW4gP5JgIV+CekoMVBfNeJguXulUyesCjGWmVxt9FRDUpxq+trBwlq/4f21obgTS4F6muAWG4l50fGP8epx4ne99/GvHnzrT8LpooT3LAiwebP8fLv8SuuJRUipNSQ9NUbJ2BJWt+FbOeI= Content-Type: text/plain; charset="us-ascii" Content-ID: <7E6B047CA8C794479E6A7D3BE9D76BF6@namprd15.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: eb5f5fd2-c287-4158-9df5-08d69b89eddc X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Feb 2019 01:30:01.6912 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1886 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-02-26_01:,, signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Mon, Feb 25, 2019 at 03:14:38PM -0800, Stanislav Fomichev wrote: [ ... ] > >=20 > > To ensure it is only called from BPF_CGROUP_INET_EGRESS, the > > attr->expected_attach_type must be specified as BPF_CGROUP_INET_EGRESS > > during load time if the prog uses this new helper. > > The newly added prog->enforce_expected_attach_type bit will also be set > > if this new helper is used. This bit is for backward compatibility rea= son > > because currently prog->expected_attach_type has been ignored in > > BPF_PROG_TYPE_CGROUP_SKB. During attach time, > > prog->expected_attach_type is only enforced if the > > prog->enforce_expected_attach_type bit is set. > > i.e. prog->expected_attach_type is only enforced if this new helper > > is used by the prog. > >=20 [ ... ] > > @@ -1725,6 +1733,10 @@ static int bpf_prog_attach_check_attach_type(con= st struct bpf_prog *prog, > > case BPF_PROG_TYPE_CGROUP_SOCK: > > case BPF_PROG_TYPE_CGROUP_SOCK_ADDR: > > return attach_type =3D=3D prog->expected_attach_type ? 0 : -EINVAL; > > + case BPF_PROG_TYPE_CGROUP_SKB: > > + return prog->enforce_expected_attach_type && > > + prog->expected_attach_type !=3D attach_type ? > > + -EINVAL : 0; > > default: > > return 0; > > } [ ... ] > > diff --git a/net/core/filter.c b/net/core/filter.c > > index 97916eedfe69..ca57ef25279c 100644 > > --- a/net/core/filter.c > > +++ b/net/core/filter.c > > @@ -5426,6 +5426,24 @@ static const struct bpf_func_proto bpf_tcp_sock_= proto =3D { > > .arg1_type =3D ARG_PTR_TO_SOCK_COMMON, > > }; > > =20 > > +BPF_CALL_1(bpf_tcp_enter_cwr, struct tcp_sock *, tp) > > +{ > > + struct sock *sk =3D (struct sock *)tp; > > + > > + if (sk->sk_state =3D=3D TCP_ESTABLISHED) { > > + tcp_enter_cwr(sk); > > + return 0; > > + } > > + > > + return -EINVAL; > > +} > > + > > +static const struct bpf_func_proto bpf_tcp_enter_cwr_proto =3D { > > + .func =3D bpf_tcp_enter_cwr, > > + .gpl_only =3D false, > > + .ret_type =3D RET_INTEGER, > > + .arg1_type =3D ARG_PTR_TO_TCP_SOCK, > > +}; > > #endif /* CONFIG_INET */ > > =20 > > bool bpf_helper_changes_pkt_data(void *func) > > @@ -5585,6 +5603,13 @@ cg_skb_func_proto(enum bpf_func_id func_id, stru= ct bpf_prog *prog) > > #ifdef CONFIG_INET > > case BPF_FUNC_tcp_sock: > > return &bpf_tcp_sock_proto; >=20 > [...] > > + case BPF_FUNC_tcp_enter_cwr: > > + if (prog->expected_attach_type =3D=3D BPF_CGROUP_INET_EGRESS) { > > + prog->enforce_expected_attach_type =3D 1; > > + return &bpf_tcp_enter_cwr_proto; > Instead of this back and forth with enforce_expected_attach_type, can we > just do here: >=20 > if (prog->expected_attach_type =3D=3D BPF_CGROUP_INET_EGRESS) > return &bpf_tcp_enter_cwr_proto; > else > return null; >=20 > Wouldn't it have the same effect? The attr->expected_attach_type is currently ignored (i.e. not checked) during the bpf load time. How to avoid breaking backward compatibility without selectively enforcing prog->expected_attach_type during attach time?