Re: [patch v2 08/11] futex: Add robust futex unlock IP range

[Thomas Gleixner <tglx@kernel.org>]

On Fri, Mar 27 2026 at 14:24, Sebastian Andrzej Siewior wrote:
> On 2026-03-20 00:24:46 [+0100], Thomas Gleixner wrote:
>
> end_ip could be replaced with a u16 size. There is no need to have
> pop_size32 as u32, it could be a u16 filling the gap.
> On the other hand, pop_size32 could be passed by the caller since it is
> known if it is the first or the second member / the 64bit or 32bit case.

That's not a win because
    {
        unsigned long	start;
        u??		len;
    }

will always end up with a hole between the array entries.

> unlock_cs_num_ranges could probably go because if start_ip == NULL then
> there is no mapping since it can't be mapped at 0x0. Worst case would be
> to check two variables vs NULL.

That's correct, but it increases the costs for COMPAT as

       if (ip >= r[0].start && ip < r[0].start + r[0].end)
          // not taken
          return .....;
       if (ip >= r[1].start && ip < r[1].start + r[1].end)
          // not taken
          return .....;
        
IP is > 0, so it needs to do both checks with full evaluation. That can
be avoided by initializing the r[N].start with ~0UL, which means the first
check

        ip >= r[0].start

will be false.

> And if we replace end_ip with size then we could remove it because vdso
> is known at compile so we should know the size at compile time.

No, it's not because the VDSO is a user space build and the kernel
relies on vdso2c to convert it to a binary blob, which is mapped to user
space and the pre?ap-pended container for extable, alternatives and
symbols the kernel needs. And no, the build dependency mess is big
enough already, no need to make it worse.

Thanks,

        tglx