Re: [PATCH 1/4] export __put_task_struct for XPMEM

On Mon, Aug 27, 2007 at 09:47:52PM +0100, Al Viro wrote:

On Mon, Aug 27, 2007 at 03:24:20PM -0500, Robin Holt wrote:

quoted

On Mon, Aug 27, 2007 at 08:35:10PM +0100, Al Viro wrote:

quoted

On Mon, Aug 27, 2007 at 02:19:06PM -0500, Dean Nelson wrote:

quoted

No operations can be done once it's closed, only while it's opened.

What the hell do you mean, can't be done?

	fd = open(...);
	fp = popen("/bin/date", "r");
	/* read from fp */
	fclose(fp);

But this will operate on the dup'd fd.  We detect that in the flush
(ignore) and ioctl (return errors) operations.  All other operations
are not handled by xpmem.

How the hell do you detect dup'd fd?  It's identical to the original
in every respect and it doesn't have to be held by a different task.

I attached that to the previous email.  We have a thread group structure
which is reference by tgid.  This comes from current->tgid.  For a fork'd
process, that tgid will be different.  Until that child process does
an open of /dev/xpmem, anything the child tries to do with xpmem will
not find the child's thread group structure and will return immediately.
We are not storing anything into or relating anything to the fd.  We are
dealing strictly with our own structures referenced by current->tgid.

Seriously, what you are proposing makes no sense whatsoever...

I guess I am too close to this because it makes perfect sense to me.
The way I view it, we have a device special file which provides us a set
of ioctl()s which enable multiple processes to share the same physical
pages of memory including memory from other partitions of the same system.

Those pages need to be demand faulted.  That will require us to
call get_user_pages() which will require us to have a reference to
the task_struct and mm_struct for the process which made that memory
available.  The undoing of the reference will require us use put_task()
and mm_put().

We are certainly open to alternative methods of faulting in those pages.
We have been working on and with this code since 2001 and may be too
used to our current method of doing things.  If you have suggestions
for doing this differently, we would love to hear about them.

Thanks,
Robin