[cgl_discussion] coding detail

Dave Olien dmo at osdl.org
Thu Apr 3 13:05:03 PST 2003


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



More information about the cgl_discussion mailing list