arch: arc: fixes the case triggering a cpu exception in user mode

[vonhust]

• raise software triggerd exception unconditionally
• fix the handling when exception raised in irq context
• software-trigger exception only allow oops and stack check fail
• remove the exception of arc in tests/mem_protection/userspace

Fixes #17899 #17590

[ruuddw]

Not sure if it's relevant or not, but this seems to change the behavior for the kernel non-isr case: it doesn't trigger an exception anymore. Alternative would be to first test for user mode, and then test for interrupt context (I assume that is to avoid fatal double exception?)

[vonhust]

Not sure if it's relevant or not, but this seems to change the behavior for the kernel non-isr case: it doesn't trigger an exception anymore. Alternative would be to first test for user mode, and then test for interrupt context (I assume that is to avoid fatal double exception?)

z_except_reason/Z_ARCH_EXCEPT is actively called by kernel like k_panic, k_oops, it's a kind of SW exception, different with HW exception. So if the processor in kernel mode, it has enough privilege to do things like an exception fix. Although it's also ok to raise a hardware exception by TRAP, it's not efficient because of exception prologue handling.

any thought on this? Does z_except_reason need to raise a real exception? @andrewboie

[vonhust]

I did a further look of Z_ARCH_EXCEPT. It seems to it's required to raise an cpu exception. So i made some updates that remove the check of user_context/isr.

For the case that called in exception handler, it will raise double exception. But this case is unreasonable.

[andrewboie]

any thought on this? Does z_except_reason need to raise a real exception? @andrewboie

Yes, this should trigger an exception.

[andrewboie]

Why is this check even needed?
Can't you just trigger a trap unconditionally?

[vonhust]

Now, raise exception unconditionally

[ioannisg]

It's now completely unconditional, right?

Looks ok to me, @ruuddw pls, take a look

[ioannisg]

@abrodkin could you also review?

[ruuddw]

This indeed fixes #17899. Not sure though if the ISR check isn't required to handle the case that Z_ARCH_EXCEPT is called from interrupt context. Sanity check looks clean, is there a test that calls Z_ARCH_EXCEPT from isr context? Would that be expected to work?

Also, I see a related 'FIXME' in userspace tests. ARC is excluded in test_oops ("FIXME #17590"). Can #17590 be closed now as well?

[abrodkin]

Looks good to me to.

[vonhust]

@ruuddw @andrewboie , I found why there is a condition to raise exception, i.e., whether in isr,
because there is no specific handling in exc handling code about the case where exception comes out in interrupt handling, one example is z_check_stack_sentinel will raise exception by Z_ARCH_EXCEPT.

I add another commit to fix this in this PR. Pls review, and do not merge before the sanitycheck test is clean.

[andrewboie]

This indeed fixes #17899. Not sure though if the ISR check isn't required to handle the case that Z_ARCH_EXCEPT is called from interrupt context. Sanity check looks clean, is there a test that calls Z_ARCH_EXCEPT from isr context? Would that be expected to work?

@ruuddw I'm not sure I understand.

If you trigger this while servicing an interrupt, doesn't this just induce an exception? That's what we would want.

The behavior should be:

1. Someone calls k_panic() in an ISR, because something horrible happened while servicing that interrupt.
2. A fatal error is generated with reason code K_ERR_KERNEL_PANIC

I don't know if there's a test for this scenario, it should be reasonable to implement using irq_offload().

[ruuddw]

Thanks Wayne, this fixes both #17899 and #17590, and addresses raising an exception from interrupt context.

[wentongwu]

@ruuddw @vonhust @andrewboie @nashif can we backport this PR to v1.14 branch?

[andrewboie]

@wentongwu agree this looks like it should be backported. I would recommend look at all other arch/arc patches I am not sure if all ARC userspace patches have been backported since 1.14. there were a lot of things fixed after 1.14

[wentongwu]

@andrewboie yes, checked the commit history, lots of enhancement/fix for user space added, I don't think user space on arc will work well without them. It would be better if these patches can be backported to v1.14 branch.

@ruuddw is it possible to do that backport for arc?

[ruuddw]

We've done few backports, but there have been many enhancements (to support SMP) as well that we didn't backport.
Let me see if we missed some essential ones.