mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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.



  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®