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=-15.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 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 41A85C433DB for ; Fri, 29 Jan 2021 01:10:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 040E564DED for ; Fri, 29 Jan 2021 01:10:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231796AbhA2BJi (ORCPT ); Thu, 28 Jan 2021 20:09:38 -0500 Received: from www62.your-server.de ([213.133.104.62]:42830 "EHLO www62.your-server.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231397AbhA2BJ1 (ORCPT ); Thu, 28 Jan 2021 20:09:27 -0500 Received: from sslproxy02.your-server.de ([78.47.166.47]) by www62.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1l5IHF-0008NN-PA; Fri, 29 Jan 2021 02:08:45 +0100 Received: from [85.7.101.30] (helo=pc-9.home) by sslproxy02.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1l5IHF-0002Do-KA; Fri, 29 Jan 2021 02:08:45 +0100 Subject: Re: [PATCH bpf-next v2 4/4] bpf: enable bpf_{g,s}etsockopt in BPF_CGROUP_UDP{4,6}_RECVMSG To: Stanislav Fomichev Cc: Netdev , bpf , Alexei Starovoitov References: <20210127232853.3753823-1-sdf@google.com> <20210127232853.3753823-5-sdf@google.com> <3098d1b1-3438-6646-d466-feed27e9ba6b@iogearbox.net> From: Daniel Borkmann Message-ID: Date: Fri, 29 Jan 2021 02:08:39 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Authenticated-Sender: daniel@iogearbox.net X-Virus-Scanned: Clear (ClamAV 0.102.4/26063/Thu Jan 28 13:28:06 2021) Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On 1/29/21 1:59 AM, Stanislav Fomichev wrote: > On Thu, Jan 28, 2021 at 4:52 PM Daniel Borkmann wrote: >> On 1/28/21 12:28 AM, Stanislav Fomichev wrote: >>> Those hooks run as BPF_CGROUP_RUN_SA_PROG_LOCK and operate on >>> a locked socket. >>> >>> Signed-off-by: Stanislav Fomichev >>> --- >>> net/core/filter.c | 4 ++++ >>> tools/testing/selftests/bpf/progs/recvmsg4_prog.c | 5 +++++ >>> tools/testing/selftests/bpf/progs/recvmsg6_prog.c | 5 +++++ >>> 3 files changed, 14 insertions(+) >>> >>> diff --git a/net/core/filter.c b/net/core/filter.c >>> index ba436b1d70c2..e15d4741719a 100644 >>> --- a/net/core/filter.c >>> +++ b/net/core/filter.c >>> @@ -7023,6 +7023,8 @@ sock_addr_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog) >>> case BPF_CGROUP_INET6_BIND: >>> case BPF_CGROUP_INET4_CONNECT: >>> case BPF_CGROUP_INET6_CONNECT: >>> + case BPF_CGROUP_UDP4_RECVMSG: >>> + case BPF_CGROUP_UDP6_RECVMSG: >>> case BPF_CGROUP_UDP4_SENDMSG: >>> case BPF_CGROUP_UDP6_SENDMSG: >>> case BPF_CGROUP_INET4_GETPEERNAME: >>> @@ -7039,6 +7041,8 @@ sock_addr_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog) >>> case BPF_CGROUP_INET6_BIND: >>> case BPF_CGROUP_INET4_CONNECT: >>> case BPF_CGROUP_INET6_CONNECT: >>> + case BPF_CGROUP_UDP4_RECVMSG: >>> + case BPF_CGROUP_UDP6_RECVMSG: >>> case BPF_CGROUP_UDP4_SENDMSG: >>> case BPF_CGROUP_UDP6_SENDMSG: >>> case BPF_CGROUP_INET4_GETPEERNAME: >> >> Looks good overall, also thanks for adding the test cases! I was about to apply, but noticed one >> small nit that would be good to get resolved before that. Above you now list all the attach hooks >> for sock_addr ctx, so we should just remove the whole switch that tests on prog->expected_attach_type >> altogether in this last commit. > Sure, I can resend tomorrow. > But do you think it's safe and there won't ever be another sock_addr > hook that runs with an unlocked socket? Ok, that rationale seems reasonable to keep the series as is. It probably makes sense to add a small comment at least to the commit log to explain the reasoning, I can do so while applying. So no need for v3, thanks!