ARM Cortex_R: CONFIG_USERSPACE: external interrupts are disabled during system calls

[pderwin]

While processing a system call, the HANDLER code should run with external interrupts enabled. This is not the case for Cortex R.

To Reproduce

Steps to reproduce the behavior:

Produce a build for Cortex R CPU with CONFIG_USERSPACE enabled. Run test that Andrew Boie has added which checks for interrupts enabled in system call context. It will fail the following assert:
zassert_true(arch_irq_unlocked(key), "irqs locked during syscall");

his new test:
tests: userspace: test syscall irq context #21920

Expected behavior
Interrupts should be enabled during the system call, so the assert should pass.

Impact
Anyone using CONFIG_USERSPACE with Cortex_R will suffer from having interrupts disabled during system calls. This could be catastrophic depending on the user's environment.

Screenshots or console output
N/A

Environment (please complete the following information):

• OS: Linux build environment
• Toolchain Zephyr SDK
• V 1.14.0 : cebe115

Additional context
We have a fix for the problem. Ready for submission.

[jhedberg]

You're mentioning Zephyr 1.14, however cortex r wasn't supported then?

[pderwin]

We have been using Z on Cortex-R for some time. Official support may not be claimed, but we are using it and reporting/fixing bugs as we see them.

[andrewboie]

We have been using Z on Cortex-R for some time. Official support may not be claimed, but we are using it and reporting/fixing bugs as we see them.

@pderwin I'm wondering if there's a better way to track bugs in Cortex-R code that isn't upstreamed yet?

The problem with filing these bugs in the main Zephyr bug backlog, is that it gives the impression that these are issues in the main Zephyr master branch. And it will mess up our bug counts when we count them up when preparing a release.

Would it be possible to track these elsewhere, perhaps in a fork of the Zephyr project where you maintain your yet-to-be-upstreamed code, and only file issues here if they have been determined to affect the open source tree as well (such as the issue with MPU->RNR locking on Cortex-M)?

[pderwin]

I talked with my partner here. We're going to get our R code upstreamed ASAP. Actually, t has already been submitted, but not accepted due to a couple of merge conflicts.

There is a usermode test that I will get that functioning on our platform as 'proof of life'.

We believe that someone is working towards having a QEMU implementation for R4, so a regression will be possible when that's ready.

Hopefully still will all be completed before a new bug arises.

Phil

[andrewboie]

I talked with my partner here. We're going to get our R code upstreamed ASAP. Actually, t has already been submitted, but not accepted due to a couple of merge conflicts.

Works for me. Please add me as a reviewer.

[stephanosio]

Most of the Cortex-R port issues should be addressed by #20594. I suspect this bug might have something to do with #20474.

[ioannisg]

@pderwin should this bug issue be closer or treated as enhancement, as well?

[pderwin]

yes.

…

________________________________ From: Ioannis Glaropoulos <notifications@github.com> Sent: 24 July 2020 10:51 AM To: zephyrproject-rtos/zephyr <zephyr@noreply.github.com> Cc: Phil Erwin Jr <phil.erwin@lexmark.com>; Mention <mention@noreply.github.com> Subject: Re: [zephyrproject-rtos/zephyr] ARM Cortex_R: CONFIG_USERSPACE: external interrupts are disabled during system calls (#22131) @pderwin<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpderwin&data=02%7C01%7Cphil.erwin%40lexmark.com%7C97038381dd7e44ba27b708d82fe103fd%7C127090656e6c41c99e4dfb0a436969ce%7C1%7C0%7C637311990763923190&sdata=a4dLxTd%2Byi%2BtmjsXX9jHeInZIN9nn4czwWyf6nV07S8%3D&reserved=0> should this bug issue be closer or treated as enhancement, as well? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzephyrproject-rtos%2Fzephyr%2Fissues%2F22131%23issuecomment-663577381&data=02%7C01%7Cphil.erwin%40lexmark.com%7C97038381dd7e44ba27b708d82fe103fd%7C127090656e6c41c99e4dfb0a436969ce%7C1%7C0%7C637311990763923190&sdata=9tmIeqxqGZgbHJnf5s5IotIfO7EbhKukqb%2BwOIi0x0o%3D&reserved=0>, or unsubscribe<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAI2JBU3XFEWFWK3Q2VKSYUDR5GNWFANCNFSM4KKV4XEQ&data=02%7C01%7Cphil.erwin%40lexmark.com%7C97038381dd7e44ba27b708d82fe103fd%7C127090656e6c41c99e4dfb0a436969ce%7C1%7C0%7C637311990763933185&sdata=4sX5AQ2ypoeq6sQwdG9qRpSXzDiCv42kKh%2BrMavgcCg%3D&reserved=0>.

[bbolen]

This should be addressed with #28231. The Cortex-R implementation enables interrupts while handling the system call.