[cgl_discussion] Re: coding detail

[Frederic Rossi (LMC)]

Hi Dave,
   
    There cannot be any race condition here because the task context B 
has just been
created but the task has not been started yet. The constructor is running
inside the context of A and is building the parameters for B. So it is 
safe because
B cannot exit at this moment.

For the case below the accept handler can really be a process two, so 
the task can
be either 'current' or a new task. It is only in the case of AEM that 
the task pointer
can reference a structure wich is not 'current'.

Frederic



Dave Olien wrote:

>Frederic,
>
>This is just a question about a coding/implementation detail I observed
>in your code.
>
>You introduced a new kernel function:
>
>fd_install_task(struct task_struct *task, unsigned int fd, struct file *file)
>
>It allows you to install a file descriptor into a task other than
>the current task.  It's derived from the pre-existing kernel routine
>
>	fd_install(unsigned int fd, struct file *file)
>
>When I first noticed the new routine, I was worried about a race
>condition where "process A" is trying to install a file descriptor
>into "process B" while at the same time "process B" is exiting.
>"process B" and all its data structures could be deallocated while
>"process A" is still trying to write to them.
>There didn't seem to be anything to preclude this race.
>
>Since then, I've noticed the only caller of this routine is the
>routine
>
>	sockasync_aq_c()
>
>This is the "constructor routine" for delivering the event that accepts
>a connection on a socket.  My understanding of the code is that events
>are queued off of the task that is to accept delivery of the event, and
>a task's  events are delivered when that task is current.  So in fact,
>every place, fd_install_task() is called, its task argument will be
>the same as "current".
>
>The fd_install_task() function is I think a dangerous
>function, and in fact doesn't seem to be needed in your current implementation.
>It should be removed if this is true.  If it isn't true, then I need to
>understand why there isn't a race with exit.
>
>Have I misread the code?
>
>Thanks!
>
>Dave
>

-- 

Ericsson Research Canada          frederic.rossi at ericsson.ca
Systems Research LMC/UU           Phone:  (514) 345-7900  x5641
8400 Decarie Blvd.
Town of Mount Royal
H4P 2N2, (Quebec) Canada