RE: [PATCH 1/3] [POC] test implementaion of rt-signals

[Johannes Kirchmair <johannes.kirchmair@sigmatek.at>]

> -----Original Message-----
> From: Jan Kiszka <jan.kiszka@siemens.com>
> Sent: Freitag, 1. September 2023 16:12
> To: Johannes Kirchmair <johannes.kirchmair@sigmatek.at>;
> xenomai@lists.linux.dev
> Subject: Re: [PATCH 1/3] [POC] test implementaion of rt-signals
> 
> CAUTION: External E-Mail !
> 
> On 01.09.23 15:51, Jan Kiszka wrote:
> > On 16.08.23 12:18, Johannes Kirchmair wrote:
> >> +int xnarch_setup_trap_info(unsigned int vector, struct pt_regs *regs,
> >> +                       long errcode, int *sig, struct kernel_siginfo *info)
> >> +{
> >> +    switch (vector) {
> >> +    case 0: /* divide_error */
> >> +            *sig = SIGFPE;
> >> +            info->si_signo = *sig;
> >> +            info->si_errno = 0;
> >> +            info->si_code = FPE_INTDIV;
> >> +            info->si_addr = (void __user *)regs->ip;
> >> +            return 0;
> >> +    case 1: /* trap_error */ {
> >> +            unsigned long condition;
> >> +            get_debugreg(condition, 6);
> >> +            set_debugreg(0, 7);
> >
> > This looks suspicious: We modify DR7 unconditionally, even if we do not
> > handle the signal? Is that OK for the kernel code that takes over then
> > because it will simply do the same?
> >
> 
> I fact, I'm not sure if we can solve any real problem by permitting the
> application to catch breakpoint or single-step events over RT threads.
> 
> We do have the use case of hooking in with a high-prio RT handler prior
> to a debug stop of an RT process, and we have a downstream approach for
> that. But that is using a special monitor threat and cannot be
> re-modeled via synchronous signals this way.
> 
> For now, I would leave out DB and BP traps.
Removed it for now and added the code for SEGV from one of the previous mails.

Johannes

> 
> Jan
> 
> --
> Siemens AG, Technology
> Linux Expert Center