On Mon, 2025-06-23 at 08:05 +0200, Viktor Malik wrote:
> On 6/20/25 20:06, Alexei Starovoitov wrote:
> > On Fri, Jun 20, 2025 at 5:33 AM Viktor Malik <vmalik@xxxxxxxxxx>
> > wrote:
> > >
> > > > +SEC("syscall") __retval(USER_PTR_ERR) int
> > > > test_strnstr_user_ptr2(void *ctx) { return bpf_strnstr("hello",
> > > > user_ptr, 1); }
> > >
> > > For some reason, these tests are failing on s390x. I'll
> > > investigate.
> >
> > I suspect this is the reason for failures:
> >
> > +char *user_ptr = (char *)1;
> > +char *invalid_kern_ptr = (char *)-1;
>
> Actually, the kernel address works fine, it's the userspace addresses
> causing the problem (user_ptr and NULL). On s390,
> __get_kernel_nofault
> always returns 0 for these addresses instead of going to the
> exception
> table.
>
> > Ilya,
> >
> > Please suggest user/kern addresses to use for these tests.
>
> FWIW, I've also tried a couple other random userspace addresses, for
> all
> of them __get_kernel_nofault returned 0.
>
> In string kfuncs, 0 is treated as the end of the string (not an
> error),
> so, unless some s390 expert has a better solution, the best I can
> think
> of here is to disable the userspace addresses tests on s390.
>
> Viktor
Unfortunately NULL is a valid kernel pointer on s390; this is very
annoying, but unlikely to change any time soon.
Also, s390 has overlapping kernel and user address spaces. This means
that you cannot deduce by the value of an address whether it's a
kernel or a user address; something like 0x400000 can be both valid
kernel and user address. Normal dereferences access the kernel address
space; in order to access the user address space, one has to use magic
machine instructions.
So I would disable both NULL and invalid user_ptr tests on s390, since
they do not apply. I would still test for an invalid kernel_ptr though;
accessing (char *)-1 should cause an exception on s390.
