On 02/20/2013 10:12 PM, Jakub Jermar wrote: > 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.
Ok, I dealt with the issue in mainline,1744 and mainline,1745. The first task is simply held by an extra reference count for the entire lifespan of they system until someone calls task_done(). Jakub _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
