Re: kernel thread as real threads..

On Mon, 23 Jan 2006, Julian Elischer wrote:

> John Baldwin wrote:
>
>> On Thursday 19 January 2006 21:56, Julian Elischer wrote:
>> 
>>> some progrsss..
>>> as the first few lines show, it's not quite perfect yet but it's most of
>>> the way there..
>>> (Like proc 1 isn't init)
>> 
>> One other note, watch out for the AIO daemons.  They have to be kernel 
>> procs and not kthreads because they borrow the vmspace of the user process 
>> when performing AIO on another process' behalf.
>> 
> yeah I found that and the patches account for that.
>
> However I would like to suggest that we change the way that aio works..
>
> My suggestion is that when a process does AIO, that we "fork a ksegroup" and 
> attach it to the process, and assign it a (or some) worker thread to do the 
> aio work.  The userland process would be oblivious of the extra (kernel) 
> threads in that kseg and they would be independently schedulable. They would 
> however automatically have full access to the correct address space.

While I think that, in principle, this is the right thing to do, I'm a bit 
worried about doing it in practice.  One of the things I like about the 
current aio code is the degree to which the the aio daemon processes are 
independent of the original requesting process -- we acquire references to 
vmspaces, creds, file descriptors, etc, but don't keep accessing the ones of 
the process.  This means that if a process changes its uid, changes its 
threading, etc, while aio is running, aio is relatively unaffected.  I worry 
that if we allow tighter integration of the two, we open up the door to 
security related race conditions.  Also, we introduce concerns about the 
run-down when single-threading, exiting, execing, etc.

Robert N M Watson