Do interrupts need to be disabled during setjmp? #1

Closed
opened 9 months ago by Lephenixnoir · 4 comments
Collaborator

Currently setjmp blocks interrupts. This uses BL=1, so it could be a problem if setjmp is loaded over a page boundary with the second page unmapped during the call.

What is the rationale for blocking interrupts? All the registers considered for a save are preserved by interrupts, so I'm thinking maybe this can be avoided.

Currently [`setjmp` blocks interrupts](https://gitea.planet-casio.com/Vhex-Kernel-Core/fxlibc/src/commit/f76757ecd2fdc71aa740d15af110c7042c43768c/src/setjmp/setjmp.S#L14). This uses BL=1, so it could be a problem if `setjmp` is loaded over a page boundary with the second page unmapped during the call. What is the rationale for blocking interrupts? All the registers considered for a save are preserved by interrupts, so I'm thinking maybe this can be avoided.
Owner

The fact that I set SR.BL=1 instead of SR.IMASK=0b1111 is dangerous effectively, and should be changed or removed.

But, if we look at the glibc manual, this function is flagged to be Thread safety. So, if we want to get the "real" behavior of this function, the only way is to perform an atomic operation by blocking interruption when we were restoring the context.

Furthermore, this function has been written to handle threads management in Vhex and its depend on this security.

The fact that I set `SR.BL=1` instead of `SR.IMASK=0b1111` is dangerous effectively, and should be changed or removed. But, if we look at the glibc manual, this function is flagged to be `Thread safety`. So, if we want to get the "real" behavior of this function, the only way is to perform an atomic operation by blocking interruption when we were restoring the context. Furthermore, this function has been written to handle threads management in Vhex and its depend on this security.
Poster
Collaborator

I understand. Why is atomicity required though? It seems to me that if the thread is interrupted during setjmp(), the state save will simply resume once the thread is scheduled to run again. (Much like strlen() doesn't care about being interrupted.)

The same question holds for the Vhex scheduler. Note that I don't have a problem with setting IMASK=15 here, I just like to know exactly why we're doing it.

I understand. Why is atomicity required though? It seems to me that if the thread is interrupted during `setjmp()`, the state save will simply resume once the thread is scheduled to run again. (Much like `strlen()` doesn't care about being interrupted.) The same question holds for the Vhex scheduler. Note that I don't have a problem with setting IMASK=15 here, I just like to know exactly why we're doing it.
Owner

I understand. Why is atomicity required though? It seems to me that if the thread is interrupted during setjmp(), the state save will simply resume once the thread is scheduled to run again. (Much like strlen() doesn't care about being interrupted.)

Ha...effectively we don't need to do atomic operation here. We can remove it.

> I understand. Why is atomicity required though? It seems to me that if the thread is interrupted during setjmp(), the state save will simply resume once the thread is scheduled to run again. (Much like strlen() doesn't care about being interrupted.) Ha...effectively we don't need to do atomic operation here. We can remove it.
Poster
Collaborator

I finally updated setjmp for this. Feel free to roll it back if it causes problems in the thread scheduler, I might have missed some issue. ^^

I finally updated setjmp for this. Feel free to roll it back if it causes problems in the thread scheduler, I might have missed some issue. ^^
Lephenixnoir closed this issue 8 months ago
Sign in to join this conversation.
No Label
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.