Hello Sid,
On 2023-08-05 03:05, Sid Agrawal wrote:
I have a scenario and would like to understand how the kernel is expected to behave when I change the CSpace of a TCB when it is blocked on an EP.
CSpace matters when system calls are done. That is, all access checks are done at the start of the system call. So changing the CSpace afterwards should have no effect for on-going system calls.
However, there is one exception: The CSpace change can cause the last references to kernel objects to disappear, which will trigger the destruction of those objects, with all side-effects.
The root CSpace can be seen as a special cap slot in the TCB object. Changing it will delete the old root cap, and if that was the only reference to the CNode, then all the objects pointed to will also lose a reference recursively. When an object has no references left, it is deleted.
- A TCB (say TCB_1) is blocked on seL4_reply() on an endpoint (say
EP_1).
I'm assuming you mean seL4_Recv() or seL4_Call() here, seL4_reply() is non-blocking.
- Now, another PD, which has the capability to TCB_1, changes the
CSpace of TCB_1 by using seL4_TCB_SetSpace(). Let's assume that the VSpace is identical.
This new CSpace can be different from the old CSpace in 4 ways: A. It doesn't have the endpoint EP_1 B. It has the endpoint EP_1 but at a different CSlot. C. It has the endpoint EP_1 at the same CSlot. But since it is a different CSpace(so CNodes shared), it is a minted copy of the EP_1. Let's call it EP_1-prime. D. It has the endpoint EP_1 at the same CSlot, and it is the same EP as I have shared the CNode containing the EP_1 from the original CSpace. New and old CSpaces share the CNode containing that EP_1 like two trees sharing a sub-tree.
So what happens depends on whether EP_1 still exists after the call, where or how it fits on the CSpace doesn't matter. That is, cases A-D all behave the same if EP_1 still exists. Only in the case of A can EP_1 disappear, in which case the system call should return an error.
Greetings,
Indan