Re: [PATCH 2/2] LoongArch: Extend the maximum number of watchpoints

[WANG Xuerui]

On 1/22/25 11:09, Tiezhu Yang wrote:
> On 01/21/2025 09:46 PM, Xi Ruoyao wrote:
> > On Tue, 2025-01-21 at 21:35 +0800, WANG Xuerui wrote:
> > > one cannot account for older (in fact, *every existing*) clients
> > > expecting the old UAPI, hence providing a smaller buffer than struct
> > > user_watch_state_v2. In which case the kernel will happily write
> > > out-of-bounds if the client asks for the current watchpoint state. This
> > > is not acceptable I'm afraid.
> >
> > Yes, many distros support running the latest kernel with an old
> > userspace for hardware compatibility reason and the change will blow up
> > gdb on all those distros.  We need to do something smarter to retain the
> > backward compatibility.
>
> Hi Xuerui and Ruoyao,
>
> The compatibility problem has been considered when developing and testing
> the patches, when the applications in the userspace get watchpoint state,
> the length will be specified which will not bigger than the sizeof struct
> user_watch_state or user_watch_state_v2, the actual length is assigned as
> the minimal value of the application and kernel in the generic ptrace:
>
> kernel/ptrace.c: ptrace_regset():
>
>      kiov->iov_len = min(kiov->iov_len,
>                          (__kernel_size_t) (regset->n * regset->size));
>
>      if (req == PTRACE_GETREGSET)
>              return copy_regset_to_user(task, view, regset_no, 0,
>                                         kiov->iov_len, kiov->iov_base);
>      else
>              return copy_regset_from_user(task, view, regset_no, 0,
>                                           kiov->iov_len, kiov->iov_base);
>
> For example, there are four kind of combinations, all of them work well.
>
> (1) "older kernel + older gdb", the actual length is 8+(8+8+4+4)*8=200;
> (2) "newer kernel + newer gdb", the actual length is 8+(8+8+4+4)*14=344;
> (3) "older kernel + newer gdb", the actual length is 8+(8+8+4+4)*8=200;
> (4) "newer kernel + older gdb", the actual length is 8+(8+8+4+4)*8=200.
>
> If you have more comments, please let me know.

Thanks for posting the analysis; it was good to know the equivalent of 
sizeof(input) handling actually resides in the arch-independent side.

But next time please just include the explanation in v1 commit message 
to save us many replies back-and-forth. ;-)

--
WANG "xen0n" Xuerui

Linux/LoongArch mailing list: https://lore.kernel.org/loongarch/