Re: [PATCH v3 0/5] microblaze: fix signal handling and the ABI argument home area

[Michael Eager <eager@eagercon.com>]

On 8/24/26 10:53 AM, Waldemar Brodkorb wrote:
> Hi Ramin, Hi all,
> Ramin Moussavi wrote,
> 
>> Five fixes to the microblaze signal-delivery path, found while bringing the
>> uClibc-ng NPTL test suite up on microblazeel under qemu-system
>> (petalogix-s3adsp1800).
>>
>> Patch 1 wires up sigaltstack(), which is routed to sys_ni_syscall even
>> though the signal code fully supports an alternate stack; microblaze is the
>> only architecture leaving it unimplemented.
>>
>> Patch 2 reserves the ABI argument home area at the top of the signal frame.
>> A handler may store its incoming arguments r5..r10 into [r1+4]..[r1+24], and
>> r1 points at struct rt_sigframe on entry, so those stores land in
>> siginfo/ucontext and corrupt the signal state.
>>
>> Patch 3 stops ret_from_trap from writing r3/r4 back into the saved pt_regs
>> after sys_rt_sigreturn() has restored the full register set.  Only r4 is
>> actually lost -- the usual *rval_p = regs->r3 idiom carries r3, but a C
>> function has no second return value for r4 -- which corrupts any register
>> live across a signal, e.g. the address held in an lwx/swx CAS loop.
>>
>> Patch 4 restores the same reservation in the kernel's own frames.  The ABI
>> rule applies to the kernel's asm-to-C calls too: with r1 at the frame base a
>> callee may spill over the saved registers, and PT_R1 is the first slot it
>> hits.  This was latent until GCC 15 changed register allocation
>> (3b9b8d6cfdf5, "ira: Scale save/restore costs of callee save registers with
>> block frequency"); a kernel built with gcc >= 15 without the
>> TARGET_CALLEE_SAVE_COST workaround dies on init's first syscall.  The kernel
>> had this reservation until 2011, when commit 6e83557c38b4 removed it as
>> suspected v850 leftovers -- this brings it back, with 28 bytes rather than
>> the historic 24, which was one word short.
>>
>> Patch 5 is Sam Price's: MSR is not round-tripped through the signal frame,
>> so the interrupted carry flag is lost across signal delivery -- the same
>> failure class as patch 3, through a different register.
>>
>> Testing: v7.2 built with gcc 16.2.0, which carries no
>> TARGET_CALLEE_SAVE_COST workaround and so reproduces the allocator change,
>> userspace built with the same compiler.  The uClibc-ng test suite reports
>> 759 passed, 0 failed, 7 skipped, unchanged from a known-good reference
>> kernel; without patch 4 the same kernel panics on init's first syscall.
>> checkpatch --strict is clean on all five.
>>
>> Tooling, per Documentation/process/generated-content.rst: patches 1-4 were
>> written with the help of an AI coding assistant (Claude, claude-opus-5) over
>> several sessions and carry an Assisted-by tag; patch 5 is Sam's, included
>> unchanged apart from a blank line checkpatch wanted.  The assistant was used
>> throughout -- reading the microblaze ABI out of the gcc backend, finding the
>> gcc change that made the bug visible, drafting the patches and changelogs,
>> and driving the qemu test runs.  Everything was reviewed and tested before
>> sending, and the numbers above come from real runs.  Two mistakes it made
>> were caught that way and are worth naming: patch 4 first used 32 bytes with
>> an alignment argument that does not hold (STACK_BOUNDARY is 32 bits, so 28
>> needs no rounding), and an early version of patch 2 was folded into patch 4,
>> which made the test suite blame the wrong change.
>>
>> Changes since v2 [1]:
>>    - From: now matches Signed-off-by, and the series is sent standalone
>>      rather than as a reply to the previous version (both requested by
>>      Michal).
>>    - Rebased onto v7.2.
>>    - Added patches 3, 4 and 5.  Patch 3 was previously sent standalone on
>>      27 July 2026.
>>    - Patches 1 and 2 are unchanged.
>>
>> [1] https://lore.kernel.org/all/cover.1780647609.git.lordrasmus@gmail.com/
> 
> Series successfully tested in Qemu System Emulation (little and big endian)
> and on Numato Mimas A7 Mini.
> Also works fine on 6.18.x kernels.
> 
> You can add:
> Tested-by: Waldemar Brodkorb <wbx@openadk.org>
> 
> best regards
>   Waldemar

Thanks Waldemar, that helps.

-- 
Michael Eager