Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp613875pxb; Wed, 27 Jan 2021 16:49:14 -0800 (PST) X-Google-Smtp-Source: ABdhPJyqgsWJQI7XZkUTEDisyB991O9Nirn/m07oMrTrZdCSMGEbPuv43lNhQfu4dO5N09XBjJN3 X-Received: by 2002:a05:6402:94f:: with SMTP id h15mr11257763edz.106.1611794954148; Wed, 27 Jan 2021 16:49:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611794954; cv=none; d=google.com; s=arc-20160816; b=cNTSdI9dPAeaR/Dbg/WwYX527SOTxj37kF0MAcYwm4Z2WmnVrv5eAj9bo+0TXeLe3v LEAMHvL6Htei+PZtFjBxcqoEb+llBq1MozL1ArH0N2l1sz0+PZvHKbbu0Ae9Ueb54O32 FEnDnJPYCYFrHEa6+6pcn9UiAupUaXki6ml2hDb8cCZWAfmjt7XcS7i9K09gMR/qNa6d RgVKAOWeJPqovmy/Fq8iVxi20vvCprdrb0KYHZ1g6SkL4T3wj06dbPTG74elj3282MMj 1qn242+UDpnflYDMkWXtSwE/oK2vOu3DFO6rKoMTkRX/vcntw+PxJbiTbsiyDCZEMkJG d+Nw== 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=BUnlD5wLx21g0V7L3S3zNSYk2oxfbZxjzKguPsz3fzk=; b=LCbCVDVPtKpDb56mrEmW7x8W7f6EeY5gTphVD3hooEtJH7lIoiPeCgYBhOlJp8ot96 f6aUzPpAzsziJCdYJcygL/ts89sDqGBkT/Cno9qDA+wC4bepr8QuBz53Vhu5Q/AIMbCN BMN6z78coqdZA7htP4nC4SWWGzuSLSMm3SviC6bXO6d2lSIQwO+WvS5opWOE4X0jUs8+ O4WXUm3MsquOEKQ9MjAbPECcDwRrxn9wsHge3oLxB2dkxbUelI3rYla0Nf/6Az5Qf6G7 0ux/fUku1L4ARBI5yDUl8D+FrlQnUxwYXsVDAEk9z/uryhLS8wWgoCDaaljZq49QhDVn MCDg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=QzD0o0Da; 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 a1si1934018edq.48.2021.01.27.16.48.49; Wed, 27 Jan 2021 16:49:14 -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=QzD0o0Da; 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 S232576AbhA0Xc0 (ORCPT + 99 others); Wed, 27 Jan 2021 18:32:26 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48340 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234823AbhA0Xbo (ORCPT ); Wed, 27 Jan 2021 18:31:44 -0500 Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A774CC061573; Wed, 27 Jan 2021 15:31:04 -0800 (PST) Received: by mail-yb1-xb31.google.com with SMTP id w24so3702586ybi.7; Wed, 27 Jan 2021 15:31:04 -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=BUnlD5wLx21g0V7L3S3zNSYk2oxfbZxjzKguPsz3fzk=; b=QzD0o0DaAUJyZ+Hv8cy1Kb4Dpaw1J+H3iLYk8s5De6qqZWfHYebPvYziAhkaa6VOkF SlGgve0Kf5c6axVSJ8Op+D8PxG76Jxg6MQaYUJDD5dpok29lvS+2+twpT3AbC6hih1UL enfS5nxZ8od2gXXcjMKpxWBGoAqsxBCJm4Rbv6Zh6BY4hWBxUXKbhh2xYqZOBA3NJjuc HJ24WB98f8Fa52st+0Ryo167WUm5xQcfoRsvxJj4ccibeb2Vjg2xS704cZTpMxorbe1y SDhFu4X8IuxEfEr6vDv1ZiSVmQeCIYwUAu0C9u+3DpTQFyMIN1q3gkUp0RAt/yZ/CdCp 4ylA== 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=BUnlD5wLx21g0V7L3S3zNSYk2oxfbZxjzKguPsz3fzk=; b=SFSLx97W2S579MA2tOXYorfjWi3hqI52sCh2oU3Bhp+s45pBg2UYMnCzYWSqsD47ui tyemB5iM36w+y5qrYTDKygNaIXPAg67KDg0B8h01FbsbsYd0AzFBZM9VypmjwgPnCwaI /C5Zp5FwFFf3v8zjsqe6ObeTX35cOSZbbLBKobFzk6XoBN3nxFQYKqBFvatboC1qsgvi B2FCRPB9M7O1Z0Hxws7pv7yrEX3BBP56EDLum1582hPQ4qN6Tvb9VdHMtgQfxb3fo0jq HrGDzxOKwMTcH0ud2p05f9HlTNYyBDQHhox9J3xNpoL1/F8d/E7Zvl8ko4pVv0+iNfBA DMpA== X-Gm-Message-State: AOAM5322IHg+Wyk23p3+dByRsj3fkiMpxGpKVlZo1Pv/Y/10VpdYoS3c IXmXl1ooOf8dYE1POVuP+Kzpp8/1aCMFe36FTnI= X-Received: by 2002:a25:a183:: with SMTP id a3mr19339891ybi.459.1611790263856; Wed, 27 Jan 2021 15:31:03 -0800 (PST) MIME-Version: 1.0 References: <20210126085923.469759-1-songliubraving@fb.com> <20210126085923.469759-3-songliubraving@fb.com> <4A77E6CE-82FE-4578-BC13-05583E2EA17D@fb.com> In-Reply-To: <4A77E6CE-82FE-4578-BC13-05583E2EA17D@fb.com> From: Andrii Nakryiko Date: Wed, 27 Jan 2021 15:30:53 -0800 Message-ID: Subject: Re: [PATCH v2 bpf-next 2/4] selftests/bpf: add non-BPF_LSM test for task local storage To: Song Liu Cc: bpf , Networking , open list , Ingo Molnar , Peter Ziljstra , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , john fastabend , KP Singh , Kernel Team , Hao Luo Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 27, 2021 at 1:43 PM Song Liu wrote: > > > > > On Jan 27, 2021, at 1:21 PM, Andrii Nakryiko wrote: > > > > On Tue, Jan 26, 2021 at 1:21 AM Song Liu wrote: > >> > >> Task local storage is enabled for tracing programs. Add two tests for > >> task local storage without CONFIG_BPF_LSM. > >> > >> The first test measures the duration of a syscall by storing sys_enter > >> time in task local storage. > >> > >> The second test checks whether the kernel allows allocating task local > >> storage in exit_creds() (which it should not). > >> > >> Signed-off-by: Song Liu > >> --- > >> .../bpf/prog_tests/task_local_storage.c | 85 +++++++++++++++++++ > >> .../selftests/bpf/progs/task_local_storage.c | 56 ++++++++++++ > >> .../bpf/progs/task_local_storage_exit_creds.c | 32 +++++++ > >> 3 files changed, 173 insertions(+) > >> create mode 100644 tools/testing/selftests/bpf/prog_tests/task_local_storage.c > >> create mode 100644 tools/testing/selftests/bpf/progs/task_local_storage.c > >> create mode 100644 tools/testing/selftests/bpf/progs/task_local_storage_exit_creds.c > >> > >> diff --git a/tools/testing/selftests/bpf/prog_tests/task_local_storage.c b/tools/testing/selftests/bpf/prog_tests/task_local_storage.c > >> new file mode 100644 > >> index 0000000000000..a8e2d3a476145 > >> --- /dev/null > >> +++ b/tools/testing/selftests/bpf/prog_tests/task_local_storage.c > >> @@ -0,0 +1,85 @@ > >> +// SPDX-License-Identifier: GPL-2.0 > >> +/* Copyright (c) 2021 Facebook */ > >> + > >> +#include > >> +#include > >> +#include > >> +#include "task_local_storage.skel.h" > >> +#include "task_local_storage_exit_creds.skel.h" > >> + > >> +static unsigned int duration; > >> + > >> +static void check_usleep_duration(struct task_local_storage *skel, > >> + __u64 time_us) > >> +{ > >> + __u64 syscall_duration; > >> + > >> + usleep(time_us); > >> + > >> + /* save syscall_duration measure in usleep() */ > >> + syscall_duration = skel->bss->syscall_duration; > >> + > >> + /* time measured by the BPF program (in nanoseconds) should be > >> + * within +/- 20% of time_us * 1000. > >> + */ > >> + CHECK(syscall_duration < 800 * time_us, "syscall_duration", > >> + "syscall_duration was too small\n"); > >> + CHECK(syscall_duration > 1200 * time_us, "syscall_duration", > >> + "syscall_duration was too big\n"); > > > > this is going to be very flaky, especially in Travis CI. Can you > > please use something more stable that doesn't rely on time? > > Let me try. > > > > >> +} > >> + > >> +static void test_syscall_duration(void) > >> +{ > >> + struct task_local_storage *skel; > >> + int err; > >> + > >> + skel = task_local_storage__open_and_load(); > >> + if (!ASSERT_OK_PTR(skel, "skel_open_and_load")) > >> + return; > >> + > >> + skel->bss->target_pid = getpid(); > > > > you are getting process ID, but comparing it with thread ID in BPF > > code. It will stop working properly if/when tests will be run in > > separate threads, so please use gettid() instead. > > Will fix. > > > > >> + > >> + err = task_local_storage__attach(skel); > >> + if (!ASSERT_OK(err, "skel_attach")) > >> + goto out; > >> + > >> + check_usleep_duration(skel, 2000); > >> + check_usleep_duration(skel, 3000); > >> + check_usleep_duration(skel, 4000); > >> + > >> +out: > >> + task_local_storage__destroy(skel); > >> +} > >> + > >> +static void test_exit_creds(void) > >> +{ > >> + struct task_local_storage_exit_creds *skel; > >> + int err; > >> + > >> + skel = task_local_storage_exit_creds__open_and_load(); > >> + if (!ASSERT_OK_PTR(skel, "skel_open_and_load")) > >> + return; > >> + > >> + err = task_local_storage_exit_creds__attach(skel); > >> + if (!ASSERT_OK(err, "skel_attach")) > >> + goto out; > >> + > >> + /* trigger at least one exit_creds() */ > >> + if (CHECK_FAIL(system("ls > /dev/null"))) > >> + goto out; > >> + > >> + /* sync rcu, so the following reads could get latest values */ > >> + kern_sync_rcu(); > > > > what are we waiting for here? you don't detach anything... system() is > > definitely going to complete by now, so whatever counter was or was > > not updated will be reflected here. Seems like kern_sync_rcu() is not > > needed? > > IIUC, without sync_ruc(), even system() is finished, the kernel may not > have called exit_creds() for the "ls" task yet. Then the following check > for null_ptr_count != 0 would fail. Oh, so waiting for exit_creds() invocation which can get delayed, I see. Would be good to make the above comment a bit more detailed, thanks! > > > > >> + ASSERT_EQ(skel->bss->valid_ptr_count, 0, "valid_ptr_count"); > >> + ASSERT_NEQ(skel->bss->null_ptr_count, 0, "null_ptr_count"); > >> +out: > >> + task_local_storage_exit_creds__destroy(skel); > >> +} > >> + > >> +void test_task_local_storage(void) > >> +{ > >> + if (test__start_subtest("syscall_duration")) > >> + test_syscall_duration(); > >> + if (test__start_subtest("exit_creds")) > >> + test_exit_creds(); > >> +} > > > > [...] > > > >> +int valid_ptr_count = 0; > >> +int null_ptr_count = 0; > >> + > >> +SEC("fentry/exit_creds") > >> +int BPF_PROG(trace_exit_creds, struct task_struct *task) > >> +{ > >> + __u64 *ptr; > >> + > >> + ptr = bpf_task_storage_get(&task_storage, task, 0, > >> + BPF_LOCAL_STORAGE_GET_F_CREATE); > >> + if (ptr) > >> + valid_ptr_count++; > >> + else > >> + null_ptr_count++; > > > > > > use atomic increments? > > Do you mean __sync_fetch_and_add()? yep > > > > >> + return 0; > >> +} > >> -- > >> 2.24.1 >