Re: [PATCH v2 bpf-next 4/4] selftests/bpf: Add test for sleepable bpf iterator programs

From: Kenny Yu <kennyyu@fb.com>
To: <andrii.nakryiko@gmail.com>
Cc: <alexei.starovoitov@gmail.com>, <andrii@kernel.org>,
	<ast@kernel.org>, <bpf@vger.kernel.org>, <daniel@iogearbox.net>,
	<kennyyu@fb.com>, <yhs@fb.com>
Subject: Re: [PATCH v2 bpf-next 4/4] selftests/bpf: Add test for sleepable bpf iterator programs
Date: Fri, 14 Jan 2022 20:30:26 -0800	[thread overview]
Message-ID: <20220115043026.1401889-1-kennyyu@fb.com> (raw)
In-Reply-To: <CAEf4BzY9s1ngF_ja_rrpY=1cNX=byVSjptNT-LaEKTsUJEfP6Q@mail.gmail.com>

Hi Andrii,

> Look at vmtest.sh under tools/testing/selftests/bpf, it handles
> building kernel, selftests and spinning up qemu instance for running
> selftests inside it.

Thanks, this helps!

> keeping generic u64 flags makes sense for the future, so I'd keep it.

That makes sense, I'll keep the flags in that case.

> But I also wanted to point out that this helper is logically in the
> same family as bpf_probe_read_kernel/user and bpf_copy_from_user, etc,
> where we have consistent pattern that first two arguments specify
> destination buffer (so buf + len) and the remaining ones specify
> source (in probe_read it's just an address, here it's tsk_addr). So I
> wonder if it would be less surprising and more consistent to reorder
> and have:
> 
> buf, len, tsk, addr, flags
>
> ?

Yeah, that looks better for consistency. Should I still keep the name
as `bpf_access_process_vm`, or call it something else to be more consistent
with the naming of the other bpf helpers? The benefit of the
`bpf_access_process_vm` name is that it makes it obvious it is wrapping
an existing function `access_process_vm`. 

Thanks for the feedback!

Kenny