On 2025-02-11 21:48:08 [-0300], Luis Claudio R. Goncalves wrote:

quoted

Couldn't you delay sending signals until after the preempt-disable
section? 

Looking at do_debug_exception,

void do_debug_exception(unsigned long addr_if_watchpoint, unsigned long esr,
			struct pt_regs *regs)
{
	const struct fault_info *inf = esr_to_debug_fault_info(esr);
	unsigned long pc = instruction_pointer(regs);

	debug_exception_enter(regs);

	if (user_mode(regs) && !is_ttbr0_addr(pc))
		arm64_apply_bp_hardening();

	if (inf->fn(addr_if_watchpoint, esr, regs)) {
		arm64_notify_die(inf->name, regs, inf->sig, inf->code, pc, esr);
	}

	debug_exception_exit(regs);
}
NOKPROBE_SYMBOL(do_debug_exception);


Do you mean executing the

	arm64_notify_die(inf->name, regs, inf->sig, inf->code, pc, esr);

after re-enabling the preemption or do you mean something more
sophisticated?

single_step_handler() and brk_handler() can both send signals. If
inf->fn returns != 0 (which seems to be only be possible for
brk_handler() out of the possible four callbacks) this this
arm64_notify_die() sends a signal.
So we have three potential signal delivers. It shouldn't matter if the
signal is sent within the preempt-disable section or outside because the
signal will be queued for current and delivered on the return to
userland. So would just need to save the details and do it outside. Now
that I actually looked at the code, this might lead to a bit of a mess
so splitting out the signal part and avoiding the preempt-off part might
better which would be the rework that Mark was talking about.

Luis

Sebastian