Re: [PATCH v19 00/14] arm64: entry: Convert to Generic Entry
From: Jinjie Ruan
Date: Sun Sep 27 2026 - 21:51:09 EST
在 2026/9/25 8:05, Kees Cook 写道:
> On Thu, Sep 24, 2026 at 05:32:14PM +0800, Jinjie Ruan wrote:
>> 在 2026/9/23 2:29, Kees Cook 写道:
>> I tested the rr test cases on a Kunpeng HIP09 (with minor adaptations,
>> since Kunpeng CPUs aren't supported by default), and the results showed
>> no regressions.
>
> Great! Thank you for getting that set up.
>
>>
>> | | 7.3-rc4 baseline | Patched |
>>
>> | ------------ |------------------------ | ------------------------- |
>> | result | 87% passed, 190 failed | 88% passed, 186 failed |
>>
>>
>> | Failure Mode | 7.3-rc4 baseline | Patched |
>> | ------------ | ---------------- | ---------- |
>> | TICK_MISMATCH | 76 | 74 |
>> | TIMEOUT | 68 | 65 |
>> | GDB_SCRIPT | 34 | 37 |
>> | PERF_EVENT_OPEN| 3 | 2 |
>> | OVERSHOOT | 1 | 0 |
>> | OTHER | 8 | 8 |
>> | -------------- | --------------- | ---------- |
>> | Total | 190 | 186 |
>
> GDB_SCRIPT failures went up? Are the tests just flaky?
Yes, you are right!
Those three tests failed in the baseline too — they just surfaced as
tick mismatches then and as GDB script timeouts now, so the
bucket boundary shifts with the race. That's flakiness, not a regression.
| changes | testcase |
| ----------------- | ---------------------------------- |
| OVERSHOOT -> TICK | clone_interruption |
| TICK -> GDB_SCRIPT | checkpoint_prctl_name |
| TICK -> GDB_SCRIPT | checkpoint_prctl_name-no-syscallbuf |
| TICK -> GDB_SCRIPT | clone_interruption-no-syscallbuf |
| PERF_OPEN -> TIMEOUT| clone_newflags |
| PASS -> TIMEOUT | pid_ns_shutdown-no-syscallbuf |
| TIMEOUT -> PASS | fstatat-no-syscallbuf |
| TIMEOUT -> PASS | futex_exit_race |
| TIMEOUT -> PASS | futex_exit_race-no-syscallbuf |
| TIMEOUT -> PASS | futex_exit_race_sigsegv |
| TIMEOUT -> PASS | futex_exit_race_sigsegv-no-syscallbuf|
>
>>> - MTE: I didn't see MTE in the cover letter's test list, and it seems
>>> relevant since patch 13 puts _TIF_MTE_ASYNC_FAULT into
>>> ARCH_EXIT_TO_USER_MODE_WORK, so an async tag check fault lands
>>> on the reworked exit path. The MTE selftests showed no differences,
>>> but a third of them don't actually run for me under QEMU, so they'd
>>> be worth running on your hardware. (Testing MTE under QEMU saw
>>
>> Turns out our arm64 machines don't support MTE; I was testing it on QEMU.
>
> Ah, dang. I wonder if we can find anyone with MTE hardware to test this.
> Any volunteers? :)
>
> -Kees
>
--
Best regards,
Jinjie