From: Vaibhav Jain
> Sent: 14 January 2016 07:51
> David Laight <david.lai...@aculab.com> writes:
>
> > I don't even claim to understand the linux model for handling process
> > address maps, nor what the cxl driver is doing, but the above looks
> > more than dodgy.
> >
> > David
>
> Thanks for reviewing the patch.
>
> Yes, It does look dodgy but is needed to handle a very corner case wherein
> the task_struct that had originally allocated the cxl context exit
> without freeing it. In case of a multi threaded user-space process this
> context can still be used by other threads.
Right, and a non-threaded process might have done a fork+exit
with the fd open (etc).
> A cxl_context holds pid of the task that allocated it since we need
> access to the mm_struct associated with the task to handle storage
> faults reported by the capi accelerator. Now in case of a MT process if
> the thread that allocated the context exits the pid becomes invalid and
> we are no more able to handle faults from the accelerator even though
> the process is still alive.
>
> In such a case the patch tries to use the task group leader pid to find
> the next alive task in the task group which can be used to handle the
> storage fault.
Unless you are extremely careful whatever you are using for the 'pid'
can get reallocated.
> We could have instead used only the task group leader for handling the
> faults but there is a possibility that even the task group leader has
> exited in which case the mm_struct associated with it will also be NULL.
It looks like you should be using mmap() to get the user pages accessible
to the driver - then you don't have a problem.
David
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
