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

[Mathieu Desnoyers <mathieu.desnoyers@efficios.com>]

On 2025-01-21 06:49, Mathieu Desnoyers wrote:
> On 2025-01-21 02:23, Ingo Molnar wrote:
>>
>> * Mathieu Desnoyers <mathieu.desnoyers@efficios.com> 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@efficios.com/
>>>
>>> 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@kernel.org>
>>
>> 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