Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

THis also has a problem (irq race condition) #3

Open
duaneellissd opened this issue Mar 28, 2023 · 0 comments
Open

THis also has a problem (irq race condition) #3

duaneellissd opened this issue Mar 28, 2023 · 0 comments

Comments

@duaneellissd
Copy link

The IRQ enable/disable in the PLIC - is a read/modify/write operation
(Either set a bit or clear a bit).

Why is this not protected by an CPU irq disable/restore?
Otherwise if an IRQ occurs in the middle of the read/modify/write operation there will be a bug in the user application - ie: The irq was not enabled or disabled like it should be Due to a race condtion.

Its ok to NOT - disable/enable/restore the IRQ - but you need to document the fact that the CALLER is responsible to disable the interrupts when you are enabling or disabling the interrupts in the PLIC .. (say that 3 times fast and you might think that is funny, hence I think this code should handle that for you)

It would be nice if the PLIC interface (and the APB bus supported ATOMIC read/writes from the RISCV - but - the ARM busses do not support atomic operations thus the ATOMIC instructions are useless on this CPU.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant