kernel thread as real threads..
Robert Watson
rwatson at FreeBSD.org
Mon Jan 23 14:49:20 PST 2006
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
More information about the freebsd-current
mailing list