From: Slava Imameev <slava.imameev@crowdstrike.com>
To: <qmo@kernel.org>
Cc: <andrii@kernel.org>, <ast@kernel.org>, <bpf@vger.kernel.org>,
<daniel@iogearbox.net>, <eddyz87@gmail.com>, <haoluo@google.com>,
<john.fastabend@gmail.com>, <jolsa@kernel.org>,
<justin.deschamp@crowdstrike.com>, <kpsingh@kernel.org>,
<linux-kernel@vger.kernel.org>, <linux-kselftest@vger.kernel.org>,
<mark.fontana@crowdstrike.com>, <martin.lau@linux.dev>,
<mykolal@fb.com>, <sdf@fomichev.me>, <shuah@kernel.org>,
<slava.imameev@crowdstrike.com>, <song@kernel.org>,
<yonghong.song@linux.dev>
Subject: Re: [PATCH bpf-next v2 2/2] selftests/bpf: Add test for bpftool access to read-only protected maps
Date: Thu, 12 Jun 2025 07:39:47 +1000 [thread overview]
Message-ID: <20250611213947.21534-1-slava.imameev@crowdstrike.com> (raw)
In-Reply-To: <aaa49f30-d571-4c7e-8135-691252ebc3c2@kernel.org>
> > + make -C tools/bpf/bpftool -s -j"$ncpus" OUTPUT="$output_dir"/ >/dev/null
> > + echo ... finished building bpftool
> > + cd "$pwd"
> > +}
>
>
> Given that you're reusing the BPF selftests infra, you shouldn't have to
> rebuild bpftool as part of the test. It's already built from the
> Makefile, and other tests just assume it's available already (see
> test_bpftool.py, test_bpftool.sh).
Agree, the build step will be removed for v3.
> > + # Test write access to the map
> > + if "$bpftool_path" map update name "$map_name" key $key value $value; then
> > + if [ "$write_should_succeed" = "true" ]; then
> > + echo " Write access to $map_name succeeded as expected"
> > + else
> > + echo " Write access to $map_name succeeded but should have failed"
> > + exit 1
> > + fi
> > + else
> > + if [ "$write_should_succeed" = "true" ]; then
> > + echo " Write access to $map_name failed but should have succeeded"
> > + exit 1
> > + else
> > + echo " Write access to $map_name failed as expected"
> > + fi
> > + fi
>
>
> Can we try to delete an item as well, please?
I added an item deletion test to v3.
> > +
> > + # Pin the map to the BPF filesystem
> > + "$bpftool_path" map pin name "$map_name" "$pin_path"
> > + if [ -e "$pin_path" ]; then
> > + echo " Successfully pinned $map_name to $pin_path"
> > + else
> > + echo " Failed to pin $map_name"
> > + exit 1
> > + fi
> > +
> > + # Test read access to the pinned map
> > + if "$bpftool_path" map lookup pinned "$pin_path" key $key; then
> > + echo " Read access to pinned $map_name succeeded"
> > + else
> > + echo " Read access to pinned $map_name failed"
> > + exit 1
> > + fi
> > +
> > + # Test write access to the pinned map
> > + if "$bpftool_path" map update pinned "$pin_path" key $key value $value; then
> > + if [ "$write_should_succeed" = "true" ]; then
> > + echo " Write access to pinned $map_name succeeded as expected"
> > + else
> > + echo " Write access to pinned $map_name succeeded but should have failed"
> > + exit 1
> > + fi
> > + else
> > + if [ "$write_should_succeed" = "true" ]; then
> > + echo " Write access to pinned $map_name failed but should have succeeded"
> > + exit 1
> > + else
> > + echo " Write access to pinned $map_name failed as expected"
> > + fi
> > + fi
>
>
> Maybe refactor lookup/update as a function that you can call before and
> after pinning the map? (I don't mind much.)
I changed it as suggested for v3.
> > +check_bpffs() {
> > + if [ -z "$BPF_FS" ]; then
> > + echo "Could not run test without bpffs mounted"
>
>
> Why not? Bpftool will attempt to mount it for you if it's not available
> (create_and_mount_bpffs_dir()).
>
> You could mount it manually to a specific location and unmount it during
> the clean-up phase, if you wanted to be sure that the test doesn't have
> any side effect on the filesystem.
I made changes as suggested for v3.
> > +# Load and attach the BPF programs to control maps access
> > +"$BPFTOOL_PATH" prog loadall "$BPF_FILE_PATH" "$BPF_DIR"/prog autoattach
> > +
> > +# Test protected map (write should fail)
> > +test_map_access "$PROTECTED_MAP_NAME" "false" "$BPFTOOL_PATH" "$BPF_DIR"
> > +
> > +# Test not protected map (write should succeed)
> > +test_map_access "$NOT_PROTECTED_MAP_NAME" "true" "$BPFTOOL_PATH" "$BPF_DIR"
>
>
> We could also test map creation here (possibly even with inner maps).
I added a test for map-of-maps creation for v3.
next prev parent reply other threads:[~2025-06-11 21:45 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-30 16:48 [PATCH bpf-next v2 1/2] bpftool: Use appropriate permissions for map access Slava Imameev
2025-05-30 16:48 ` [PATCH bpf-next v2 2/2] selftests/bpf: Add test for bpftool access to read-only protected maps Slava Imameev
2025-06-05 11:22 ` Quentin Monnet
2025-06-11 21:39 ` Slava Imameev [this message]
2025-06-05 11:22 ` [PATCH bpf-next v2 1/2] bpftool: Use appropriate permissions for map access Quentin Monnet
2025-06-11 21:06 ` Slava Imameev
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250611213947.21534-1-slava.imameev@crowdstrike.com \
--to=slava.imameev@crowdstrike.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=haoluo@google.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=justin.deschamp@crowdstrike.com \
--cc=kpsingh@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=mark.fontana@crowdstrike.com \
--cc=martin.lau@linux.dev \
--cc=mykolal@fb.com \
--cc=qmo@kernel.org \
--cc=sdf@fomichev.me \
--cc=shuah@kernel.org \
--cc=song@kernel.org \
--cc=yonghong.song@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®