Robert Watson wrote: > > 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. One might consider this a bug :-) of course the creds would be held until the operation finishes, but there is a linit as to how separate an aio request from a process should be from that 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. it would be no different from when a threaded process exits now.. With the current setup you have a whole set of worries about what to do about the thread responds when the process has already died. These worries are aqctually simplified if the thread is part of the process. (at least I believe this to be the case). > > Robert N M Watson > _______________________________________________ > freebsd-current_at_freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe_at_freebsd.org"Received on Mon Jan 23 2006 - 22:19:06 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:51 UTC