Re: [PATCH v2] arm64: ptrace: don't warn on missing siginfo in a group-stop

["Zhao Gongyi" <zhaogongyi@bytedance.com>]

Hi Will,

On 11/4/26 9:41 PM, Will Deacon wrote:
> I can't quite get my head around what it means to set NT_ARM_SYSTEM_CALL
> in this context. Suddenly, in_syscall() will return true, which has
> implications for things like signal handling that seem bizarre if we're
> not actually in a syscall. Should we be avoiding this situation to start
> with?
> 

I ran an additional arm64 KVM test with SIGUSR1 and SIGUSR2 queued at a
group-stop. After the tracer set NT_ARM_SYSTEM_CALL to __NR_getpid, the
second signal-handling pass saw syscallno=172 (the control saw -1),
although the task had not entered a syscall. I did not observe an
incorrect restart: x0 held the first signal number (10) by that point.

system_call_set() assigns syscallno before calling
update_syscall_orig_x0_after_ptrace(), so retaining the early return
will not prevent that state. I can investigate separately whether the
regset write should be rejected at such a stop.


> I was trying to limit the scope of this hack as much as possible, so I
> think I'd prefer the early return tbh (i.e. just drop the WARN_ON_ONCE()
> and update the comment).
> 

Agreed. I'll retain the early return, drop WARN_ON_ONCE(), update the 
comment, and send v3 with that minimal change.

Thanks,
Gongyi