From: Eric B Munson <ebmunson@us.ibm.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org,
rolandd@cisco.com, peterz@infradead.org, pavel@ucw.cz,
mingo@elte.hu
Subject: Re: [PATCH] ummunotify: Userspace support for MMU notifications
Date: Sat, 17 Apr 2010 21:41:27 +0400 [thread overview]
Message-ID: <20100417174127.GA3579@us.ibm.com> (raw)
In-Reply-To: <20100412160359.1d9074dc.akpm@linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 3528 bytes --]
On Mon, 12 Apr 2010, Andrew Morton wrote:
> On Mon, 12 Apr 2010 07:22:17 +0100
> Eric B Munson <ebmunson@us.ibm.com> wrote:
>
> > Andrew,
> >
> > I am resubmitting this patch because I believe that the discussion
> > has shown this to be an acceptable solution.
>
> To whom? Some acked-by's would clarify.
>
> > I have fixed the 32 bit
> > build errors, but other than that change, the code is the same as
> > Roland's V3 patch.
> >
> > From: Roland Dreier <rolandd@cisco.com>
> >
> > As discussed in <http://article.gmane.org/gmane.linux.drivers.openib/61925>
> > and follow-up messages, libraries using RDMA would like to track
> > precisely when application code changes memory mapping via free(),
> > munmap(), etc. Current pure-userspace solutions using malloc hooks
> > and other tricks are not robust, and the feeling among experts is that
> > the issue is unfixable without kernel help.
>
> But this info could be reassembled by tracking syscall activity, yes?
> Perhaps some discussion here explaining why the (possibly enhanced)
> ptrace, audit, etc interfaces are unsuitable.
>
> > We solve this not by implementing the full API proposed in the email
> > linked above but rather with a simpler and more generic interface,
> > which may be useful in other contexts. Specifically, we implement a
> > new character device driver, ummunotify, that creates a /dev/ummunotify
> > node. A userspace process can open this node read-only and use the fd
> > as follows:
> >
> > 1. ioctl() to register/unregister an address range to watch in the
> > kernel (cf struct ummunotify_register_ioctl in <linux/ummunotify.h>).
> >
> > 2. read() to retrieve events generated when a mapping in a watched
> > address range is invalidated (cf struct ummunotify_event in
> > <linux/ummunotify.h>). select()/poll()/epoll() and SIGIO are
> > handled for this IO.
> >
> > 3. mmap() one page at offset 0 to map a kernel page that contains a
> > generation counter that is incremented each time an event is
> > generated. This allows userspace to have a fast path that checks
> > that no events have occurred without a system call.
>
> OK, what's missing from this whole description and from ummunotify.txt
> is: how does one specify the target process? Does /dev/ummunotify
> implicitly attach to current->mm? If so, why, and what are the
> implications of this?
>
> If instead it is possible to attach to some other process's mmu
> activity (/proc/<pid>/ummunotity?) then how is that done and what are
> the security/permissions implications?
>
> Also, the whole thing is obviously racy: by the time userspace finds
> out that something has happened, it might have changed. This
> inevitably reduces the applicability/usefulness of the whole thing as
> compared to some synchronous mechanism which halts the monitored thread
> until the request has been processed and acked. All this should (IMO)
> be explored, explained and justified.
>
> Also, what prevents the obvious DoS which occurs when I register for
> events and just let them queue up until the kernel runs out of memory?
> presumably events get dropped - what are the reliability implications
> of this and how is the max queue length managed?
>
> Also, ioctls are unpopular. Were other intefaces considered?
>
I am reworking the Documentation to address all these questions and will
resubmit when finished.
Thanks for the feedback,
Eric
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
next prev parent reply other threads:[~2010-04-17 17:41 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-12 6:22 [PATCH] ummunotify: Userspace support for MMU notifications Eric B Munson
2010-04-12 20:20 ` Pavel Machek
2010-04-12 23:03 ` Andrew Morton
2010-04-12 23:59 ` Jason Gunthorpe
2010-04-13 8:29 ` Håkon Bugge
2010-04-13 17:57 ` Roland Dreier
2010-04-13 18:02 ` Peter Zijlstra
2010-04-14 5:18 ` Håkon Bugge
2010-04-14 8:52 ` Gleb Natapov
2010-04-15 13:48 ` Peter Zijlstra
2010-04-14 9:06 ` Gleb Natapov
2010-04-14 14:36 ` Jeff Squyres
2010-04-17 17:41 ` Eric B Munson [this message]
2010-04-14 16:43 ` [PATCH] ummunotify: fix umn-test build Randy Dunlap
2010-04-17 17:44 ` Eric B Munson
2010-04-18 14:38 ` Roland Dreier
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=20100417174127.GA3579@us.ibm.com \
--to=ebmunson@us.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=pavel@ucw.cz \
--cc=peterz@infradead.org \
--cc=rolandd@cisco.com \
/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;
as well as URLs for NNTP newsgroup(s).