Re: [PATCHv4 bpf-next 2/3] selftests/bpf: Add tracing_multi link info tests

[Jiri Olsa <olsajiri@gmail.com>]

On Mon, Jun 29, 2026 at 09:34:06PM +0000, sashiko-bot@kernel.org wrote:

SNIP

> > +static void verify_tracing_multi_invalid_user_buffer(int fd, const struct tmulti_target *targets)
> > +{
> > +	__u32 ids[TRACING_MULTI_CNT] = {};
> > +	struct bpf_link_info info;
> > +	__u32 len = sizeof(info);
> > +	int err, i;
> [ ... ]
> > +	/* Invalid addrs pointer -> EFAULT */
> > +	memset(&info, 0, sizeof(info));
> > +	info.tracing_multi.addrs = 0x1;
> > +	info.tracing_multi.count = TRACING_MULTI_CNT;
> > +	err = bpf_link_get_info_by_fd(fd, &info, &len);
> > +	ASSERT_EQ(err, -EFAULT, "tracing_multi.bad_addrs");
> 
> [Severity: Medium]
> Will this test actually return -EFAULT?
> 
> By zeroing out the info struct before these checks, the mandatory ids
> pointer is left as NULL while count is non-zero. If the kernel validation
> logic eagerly rejects the missing ids array with -EINVAL before reaching
> the -EFAULT paths, won't this assertion fail?

there's no such eager reject in bpf_tracing_multi_link_fill_link_info,
the test passes

jirka