Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1324304pxb; Fri, 22 Jan 2021 12:40:46 -0800 (PST) X-Google-Smtp-Source: ABdhPJyjN13IjnwVdls0hdA4ift0PT09HNWgz+L7Mc5oced3TCgF4LD46qxhl+C83E+EEqjG5lv/ X-Received: by 2002:a17:906:dbe7:: with SMTP id yd7mr4208076ejb.242.1611348046391; Fri, 22 Jan 2021 12:40:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611348046; cv=none; d=google.com; s=arc-20160816; b=E9tJn1Kkbcg/qeJBwaqoIepEh5KBaXKi4r4hA5ZVAOz0OD9ftHB9k7l1OrpzA9VtNQ zL8DnT2eiV1TzpFALbOk/j8o9DnH+vI3PvEEk5CoALeJZTaGs8SI19xYC2l3M32DfDWG KIvcw7Dm/2+6+qGKtSFymsnVwXicydas0FOgJf5I7MyedZEjp0JBubSGCtTvz+phhAMF H6sZLXqFuHGubXum3TlUKeCREqJwjdg0z1lwXm2srRxv9qOCjJkTZbbpctMALg6ANi1n JMhYq6zwYRn38d7gtIrAvmY+GeXlMcMigaJG6plTZJwIARTCLII0raM0BiVkJxyi9Dcl webw== 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=Q0GZ7NuevMmCMIuPI0eOAmyldT5LRIFt3Apaz8yFSO8=; b=swOrSH0+3tbeC/qSa8/jo5w/UOx/tn9auMQnZmBrQUZSTFn8agNJ/TWoneay8HZhfl bvE2eweX2eqEAL2gJzl52JL5zJTs72h0ncDtE8WyWAhsCKp09cTixL60SguuSOD0J+RF 2MI6b1Z1lLaCu+eNsrTiNPngLn9w52NZtCWM5uOWSYsjLtBrCBbqOzzdTORiLfcoayeI C2Dh3EqTkcWEOOobWZGyD0KHrN3JtuB4Ahqzg6FQEDAP5pH+Cpi8aGkk4lBS/GblLT4F LFkI/XJjXBR/rPeK+znZ5Oq0YS0QEKMYW0XWUokT+CoNqTb1Rg/BDFjnJCIuzjYhP6W9 7CPQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=NnsP8lLa; 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 ld19si1048295ejb.248.2021.01.22.12.40.22; Fri, 22 Jan 2021 12:40:46 -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=20161025 header.b=NnsP8lLa; 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 S1729804AbhAVUg5 (ORCPT + 99 others); Fri, 22 Jan 2021 15:36:57 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44884 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729568AbhAVUdF (ORCPT ); Fri, 22 Jan 2021 15:33:05 -0500 Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com [IPv6:2607:f8b0:4864:20::b2f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3CAB2C06174A; Fri, 22 Jan 2021 12:32:50 -0800 (PST) Received: by mail-yb1-xb2f.google.com with SMTP id k4so6696091ybp.6; Fri, 22 Jan 2021 12:32:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Q0GZ7NuevMmCMIuPI0eOAmyldT5LRIFt3Apaz8yFSO8=; b=NnsP8lLaIUuEVQJndMp0ZMQpSrHbQWGP/mSgSnedY0FgEne6Jw9G7C9LFDlqKkpvoM N5NqLaqHgcIlc2WWszawJY/I14Tv72xIkCwD9nZrvwHagh5Fvxgfdnz0HKMqfRkkKOMy qWCq6HfyRKWDVjHYPWNQ4OUhG5H3BvMr6Kx7KxyL1gF1bc7/6WwIp6tRYUJBOOhpVYn1 57S9wnCloQHHijIiKfcniY7RWzBeIDqBiCBqI/ID4WfYYfKKElyqmqN8nNq1OpXzOsuQ b7+h4PypTBh78F1oS0f40G0g/DYTJjka9vfezyUJzJ4Zbd1FN/8L/D5idoYvNd1AFyXr F1cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Q0GZ7NuevMmCMIuPI0eOAmyldT5LRIFt3Apaz8yFSO8=; b=Hk43FFN4y+VSCadIWjGADlOvnO3SJsLLXzdSZXI0YEjEg8CQPCRzdw0bZo15uetJSD D88lKhzI1l58S/I7+mhACPILvCE/26b5uUdK4bALnOfj/S9f4YA8bnubht/aZRJbdY9g b3Do00pCeBghfdM1av9IM/eI1TTeuqiqOLAkBKY/fZFUK4ebCmWaC5tE/kmFdRBPaPsQ QC6ydZj6ewlAfvERuwdeD3WQWpb5CvoKHGkMutxzR5iEAOFdEvIfm1VRKxsL7pEJty5n aMxk7lEDDHdzS5fvBTs/+WPbliEOytQjDEscmaiC6QjbAacs5djGZ9iCbT1VmzVEEERY 1uIA== X-Gm-Message-State: AOAM533U37Ho1AcZKnSRaLzlWM43IGdQTOM2gKATazPfaZa08hu2POws AV406kk6XradtcKinzx+P/q8Ghas5p5oJ5RiKuU= X-Received: by 2002:a25:4b86:: with SMTP id y128mr8724204yba.403.1611347569578; Fri, 22 Jan 2021 12:32:49 -0800 (PST) MIME-Version: 1.0 References: <20210119155953.803818-1-revest@chromium.org> <20210119155953.803818-3-revest@chromium.org> In-Reply-To: From: Andrii Nakryiko Date: Fri, 22 Jan 2021 12:32:38 -0800 Message-ID: Subject: Re: [PATCH bpf-next v5 3/4] selftests/bpf: Integrate the socket_cookie test to test_progs To: Florent Revest Cc: bpf , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , KP Singh , Florent Revest , open list Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 22, 2021 at 6:35 AM Florent Revest wrote: > > On Thu, Jan 21, 2021 at 8:55 AM Andrii Nakryiko > wrote: > > > > On Tue, Jan 19, 2021 at 8:00 AM Florent Revest wrote: > > > > > > Currently, the selftest for the BPF socket_cookie helpers is built and > > > run independently from test_progs. It's easy to forget and hard to > > > maintain. > > > > > > This patch moves the socket cookies test into prog_tests/ and vastly > > > simplifies its logic by: > > > - rewriting the loading code with BPF skeletons > > > - rewriting the server/client code with network helpers > > > - rewriting the cgroup code with test__join_cgroup > > > - rewriting the error handling code with CHECKs > > > > > > Signed-off-by: Florent Revest > > > --- > > > > Few nits below regarding skeleton and ASSERT_xxx usage. > > > > > tools/testing/selftests/bpf/Makefile | 3 +- > > > .../selftests/bpf/prog_tests/socket_cookie.c | 82 +++++++ > > > .../selftests/bpf/progs/socket_cookie_prog.c | 2 - > > > .../selftests/bpf/test_socket_cookie.c | 208 ------------------ > > > > please also update .gitignore > > Good catch! > > > > 4 files changed, 83 insertions(+), 212 deletions(-) > > > create mode 100644 tools/testing/selftests/bpf/prog_tests/socket_cookie.c > > > delete mode 100644 tools/testing/selftests/bpf/test_socket_cookie.c > > > > > > > [...] > > > > > + > > > + skel = socket_cookie_prog__open_and_load(); > > > + if (CHECK(!skel, "socket_cookie_prog__open_and_load", > > > + "skeleton open_and_load failed\n")) > > > > nit: ASSERT_PTR_OK > > Ah great, I find the ASSERT semantic much easier to follow than CHECKs. > > > > + return; > > > + > > > + cgroup_fd = test__join_cgroup("/socket_cookie"); > > > + if (CHECK(cgroup_fd < 0, "join_cgroup", "cgroup creation failed\n")) > > > + goto destroy_skel; > > > + > > > + set_link = bpf_program__attach_cgroup(skel->progs.set_cookie, > > > + cgroup_fd); > > > > you can use skel->links->set_cookie here and it will be auto-destroyed > > when the whole skeleton is destroyed. More simplification. > > Sick. :) > > > > + if (CHECK(IS_ERR(set_link), "set-link-cg-attach", "err %ld\n", > > > + PTR_ERR(set_link))) > > > + goto close_cgroup_fd; > > > + > > > + update_link = bpf_program__attach_cgroup(skel->progs.update_cookie, > > > + cgroup_fd); > > > > same as above, no need to maintain your link outside of skeleton > > > > > > > + if (CHECK(IS_ERR(update_link), "update-link-cg-attach", "err %ld\n", > > > + PTR_ERR(update_link))) > > > + goto free_set_link; > > > + > > > + server_fd = start_server(AF_INET6, SOCK_STREAM, "::1", 0, 0); > > > + if (CHECK(server_fd < 0, "start_server", "errno %d\n", errno)) > > > + goto free_update_link; > > > + > > > + client_fd = connect_to_fd(server_fd, 0); > > > + if (CHECK(client_fd < 0, "connect_to_fd", "errno %d\n", errno)) > > > + goto close_server_fd; > > > > nit: ASSERT_OK is nicer (here and in few other places) > > Did you mean ASSERT_OK for the two following err checks ? > > ASSERT_OK does not seem right for a fd check where we want fd to be > positive. ASSERT_OK does: "bool ___ok = ___res == 0;" > > I will keep my "CHECK(fd < 0" but maybe there could be an > ASSERT_POSITIVE that does "bool ___ok = ___res >= 0;" Ah, I missed that it's returning FD, sorry. For FD we'd have to add the ASSERT_GEQ(fd, 0, "blah") variant. So yeah, stick to CHECK for now. > > > > + > > > + err = bpf_map_lookup_elem(bpf_map__fd(skel->maps.socket_cookies), > > > + &client_fd, &val); > > > + if (CHECK(err, "map_lookup", "err %d errno %d\n", err, errno)) > > > + goto close_client_fd; > > > + > > > + err = getsockname(client_fd, (struct sockaddr *)&addr, &addr_len); > > > + if (CHECK(err, "getsockname", "Can't get client local addr\n")) > > > + goto close_client_fd; > > > + > > > + cookie_expected_value = (ntohs(addr.sin6_port) << 8) | 0xFF; > > > + CHECK(val.cookie_value != cookie_expected_value, "", > > > + "Unexpected value in map: %x != %x\n", val.cookie_value, > > > + cookie_expected_value); > > > > nit: ASSERT_NEQ is nicer > > Indeed. > > > > + > > > +close_client_fd: > > > + close(client_fd); > > > +close_server_fd: > > > + close(server_fd); > > > +free_update_link: > > > + bpf_link__destroy(update_link); > > > +free_set_link: > > > + bpf_link__destroy(set_link); > > > +close_cgroup_fd: > > > + close(cgroup_fd); > > > +destroy_skel: > > > + socket_cookie_prog__destroy(skel); > > > +} > > > > [...]