Hi Martin, On 02/20/2013 05:08 PM, Martin Sucha wrote: > I noticed that a pointer to the first loaded task's (usually ns) > answerbox is stored in a global variable ipc_phone_0 in > kernel/generic/src/main/kinit.c:252. > This variable is used to connect the first phone of each subsequent new > task (in kernel/generic/src/proc/task.c:219-221). What I couldn't find > though is where a reference count of the task which contains the > ipc_phone_0 answerbox is incremented for this usage. > > Suppose the first task (ns) exits. Then the IPC is cleaned up (the > answerbox is deactivated and all phones currently connected to the > answerbox are slammed) and the task itself should be deallocated. > ipc_phone_0 then becomes an invalid pointer, but it is never reset to > NULL and gets used every time a userspace task requests to spawn a new > loader task (sys_program_spawn_loader syscall). Suppose such a request > happens. Sure, the answerbox has been deactivated at this time, so > ipc_phone_connect for the newly spawned task's phone 0 fails, but the > pointer to the answerbox itself is already invalid and shouldn't be used. > > Could someone more knowledgeable please explain if there is a bit of > code that prevents this scenario from happening (i.e. what prevents the > task being deallocated) and if so, point me to it?
It's simple, this is a bug. If NS is killed, then indeed there will be a dangling pointer in ipc_phone_0. Have you hit this under normal circumstances? We will need to take this possibility into account. In other situations, it should not possible to connect to a deallocated answerbox because there needs to be at least one already existing connection to it for a new connection to be setup. Jakub _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
