From: Robin Holt <holt@sgi.com>
To: Al Viro <viro@ftp.linux.org.uk>
Cc: Robin Holt <holt@sgi.com>, Dean Nelson <dcn@sgi.com>,
akpm@linux-foundation.org, linux-ia64@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
tony.luck@intel.com, jes@sgi.com
Subject: Re: [PATCH 1/4] export __put_task_struct for XPMEM
Date: Tue, 28 Aug 2007 07:09:53 -0500 [thread overview]
Message-ID: <20070828120952.GC3648@lnx-holt.americas.sgi.com> (raw)
In-Reply-To: <20070827204752.GK21089@ftp.linux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 2256 bytes --]
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:
> > On Mon, Aug 27, 2007 at 08:35:10PM +0100, Al Viro wrote:
> > > On Mon, Aug 27, 2007 at 02:19:06PM -0500, Dean Nelson wrote:
> > >
> > > > 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
[-- Attachment #2: Type: message/rfc822, Size: 5138 bytes --]
From: Robin Holt <holt@sgi.com>
To: Al Viro <viro@ftp.linux.org.uk>
Cc: Dean Nelson <dcn@sgi.com>, akpm@linux-foundation.org, linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, tony.luck@intel.com, jes@sgi.com
Subject: Re: [PATCH 1/4] export __put_task_struct for XPMEM
Date: Mon, 27 Aug 2007 15:24:20 -0500
Message-ID: <20070827202420.GE22922@lnx-holt.americas.sgi.com>
On Mon, Aug 27, 2007 at 08:35:10PM +0100, Al Viro wrote:
> On Mon, Aug 27, 2007 at 02:19:06PM -0500, Dean Nelson wrote:
>
> > 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.
If you look at the fourth patch, at the beginning of the xpmem_flush
function, we have:
+ tg = xpmem_tg_ref_by_tgid(xpmem_my_part, current->tgid);
+ if (IS_ERR(tg))
+ return 0; /* probably child process who inherited fd */
This will protect the xpmem structures of the parent from closes by
the child.
Thanks,
Robin
-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2007-08-28 12:09 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-27 15:56 [PATCH 0/4] SGI Altix cross partition memory (XPMEM) Dean Nelson
2007-08-27 15:59 ` [PATCH 1/4] export __put_task_struct for XPMEM Dean Nelson
2007-08-27 16:13 ` Al Viro
2007-08-27 18:10 ` Dean Nelson
2007-08-27 18:15 ` Al Viro
2007-08-27 19:19 ` Dean Nelson
2007-08-27 19:35 ` Al Viro
2007-08-27 20:24 ` Robin Holt
2007-08-27 20:47 ` Al Viro
2007-08-28 12:09 ` Robin Holt [this message]
2007-08-28 18:01 ` Christoph Hellwig
2007-08-27 16:01 ` [PATCH 2/4] export zap_page_range " Dean Nelson
2007-08-27 16:02 ` [PATCH 3/4] add new lock ordering rule to mm/filemap.c Dean Nelson
2007-08-27 16:41 ` [PATCH 4/4] add SGI Altix cross partition memory (XPMEM) driver Dean Nelson
2007-08-27 20:00 ` Adrian Bunk
2007-08-28 18:02 ` Christoph Hellwig
2007-08-28 19:00 ` Robin Holt
2007-08-28 19:05 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070828120952.GC3648@lnx-holt.americas.sgi.com \
--to=holt@sgi.com \
--cc=akpm@linux-foundation.org \
--cc=dcn@sgi.com \
--cc=jes@sgi.com \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=tony.luck@intel.com \
--cc=viro@ftp.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox