Date: Mon, 23 Jan 2006 22:50:17 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Julian Elischer <julian@elischer.org> Cc: freebsd-current@freebsd.org Subject: Re: kernel thread as real threads.. Message-ID: <20060123224756.R48094@fledge.watson.org> In-Reply-To: <43D55739.80608@elischer.org> References: <43D05151.5070409@elischer.org> <200601231616.49140.jhb@freebsd.org> <43D55739.80608@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060123224756.R48094>