On Mon, Feb 21, 2005 at 08:12:57PM +0200, Michael S. Tsirkin wrote: > Quoting r. Libor Michalek <[EMAIL PROTECTED]>: > > On Thu, Feb 17, 2005 at 04:03:59PM +0200, Michael S. Tsirkin wrote: > > > Quoting r. Libor Michalek <[EMAIL PROTECTED]>: > > > > Possible Issues > > > > > > > > - Memory locking for AIO requires a call to do_mlock() which is not a > > > > kernel exported function, the method for calling the function is not > > > > standard. > > > > > > Libor, in my eyes this is the biggest issue with this gen2 sdp code. > > > In short, I dont think using do_mlock is a good idea. > > > > I do agree that this is one of the more, if not most, problematic area > > of the code, and I like your alternative suggestion below. > > BTW, just noted that sdp_iocb.c gets current->mm directly, and keeps > this pointer cashed instead of calling get_task_mm each time. > Thus it seems a race condition may occur if the task > is exiting while the cashed value is used.
Actually, the AIO code itself, outside of SDP, is incrementing the mm reference count for each submitted IO which has a one-to-one mapping with sdpc_iocb instances. We cannot increment the reference count using get_task_mm() otherwise the AIO code will run into problems. The destruction of the mm, when the reference count is decremented, triggers the AIO cleanup code, which will not complete until all outstanding AIOs have been completed or canceled. If we were to increment the mm reference count using get_task_mm() then a userspace process which has outstanding AIOs and is terminated would not attempt to destroy it's mm, which would not cleanup the oustanding AIOs, which would then hang the process. > I am not fixing it since we agreed we are changing this to get_user_pages > anyway. OK. -Libor _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
