Hi Indan, That makes a lot of sense. Thanks for the explanation. Best, Sid
On Mon, Aug 7, 2023 at 3:04 AM Indan Zupancic <in...@nul.nu> wrote: > [CAUTION: Non-UBC Email] > > 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. > > > 1. 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. > > > 2. 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 > _______________________________________________ Devel mailing list -- devel@sel4.systems To unsubscribe send an email to devel-leave@sel4.systems