Re: [GIT PULL v2] Scheduler enhancements for v6.14

[Mathieu Desnoyers]

On 2025-01-21 06:49, Mathieu Desnoyers wrote:
> On 2025-01-21 02:23, Ingo Molnar wrote:
> > * Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxxxx> wrote:
> >
> > > On 20-Jan-2025 12:07:41 PM, Ingo Molnar wrote:
> > > > Linus,
> > > >
> > > > Please pull the latest sched/core Git tree from:
> > > >
> > > >     git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
> > > > sched-core-2025-01-20
> > > >
> > > >     # HEAD: 7d9da040575b343085287686fa902a5b2d43c7ca psi: Fix race 
> > > > when task wakes up before psi_sched_switch() adjusts flags
> > > >
> > > > Scheduler enhancements for v6.14:
> > >
> > > [...]
> > >
> > > >   - RSEQ enhancements:
> > > >
> > > >     - Validate read-only fields under DEBUG_RSEQ config
> > > >       (Mathieu Desnoyers)
> > >
> > > FYI, a regression introduced by this commit was reported by s390x
> > > glibc developers testing against linux-next:
> > >
> > > https://sourceware.org/pipermail/libc-alpha/2025-January/163993.html
> > >
> > > I've sent a fix here:
> > >
> > > https://lore.kernel.org/lkml/20250116205956.836074-1-mathieu.desnoyers@xxxxxxxxxxxx/
> > >
> > > The commit introducing the issue is in this PR, but not the fix.
> >
> > Indeed - with the bug RSEQ_FLAG_UNREGISTER would fail with an incorrect
> > -EFAULT return.
> >
> > I've applied your fix, and updated the pull request for Linus further
> > below. If Linus has already pulled I'll send a fixes pull request
> > separately, or Linus can apply the fix from email directly:
> >
> >    Acked-by: Ingo Molnar <mingo@xxxxxxxxxx>
> >
> > Or he can pull the sched-core-2025-01-21 tag below safely on top of
> > sched-core-2025-01-20, which will result in a diffstat of:
> >
> >    Mathieu Desnoyers (1):
> >        rseq: Fix rseq unregistration regression
> >
> >    kernel/rseq.c | 2 +-
> >    1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > Since I booted the scheduler tree on generic desktops and it was tested
> > on other systems as well and nothing appeared to be broken, I presume
> > RSEQ_FLAG_UNREGISTER is used only in libc syscall-testcases and in
> > specific applications?
>
> Nowadays, rseq unregistration is used by specialized applications (e.g.
> tcmalloc) which disable glibc rseq support with the glibc tunable
> and register it themselves. (GLIBC_TUNABLES=glibc.pthread.rseq=0)
>
> A recent glibc (2.35+) don't use explicit rseq unregistration, it's
> unregistered implicitly when the thread exits.
>
> I'll make a note to add a test case for GLIBC_TUNABLES=glibc.pthread.rseq=0
> in the rseq selftests and librseq to improve test coverage when using a
> recent glibc.
>
> We have all the code in there to use rseq unregistration, but it is skipped
> when glibc 2.35+ is handling the registration.

It turns out that it is covered by both librseq and glibc tests, just
not by the kernel rseq selftests:

librseq test: tests/syscall_errors_test.c
glibc test: sysdeps/unix/sysv/linux/tst-rseq-disable.c

We should import the librseq test into the kernel rseq selftests as
well. CCing Michael Jeanson who will take care of this.

Thanks,

Mathieu

--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com