From: Roland Dreier <rdreier@cisco.com>
To: Li Zefan <lizf@cn.fujitsu.com>
Cc: Andrew Morton <akpm@linux-foundation.org>, linux-kernel@vger.kernel.org,
       Jeff Squyres <jsquyres@cisco.com>
Subject: Re: [PATCH/RFC] ummunot: Userspace support for MMU notifications
References: <ada3a8oobis.fsf@cisco.com>
	<20090722111538.58a126e3.akpm@linux-foundation.org>
	<adad47smsb5.fsf@cisco.com> <4A682795.8050609@cn.fujitsu.com>
Date: Thu, 23 Jul 2009 13:28:01 -0700
In-Reply-To: <4A682795.8050609@cn.fujitsu.com> (Li Zefan's message of "Thu, 23
	Jul 2009 17:04:21 +0800")
Message-ID: <adafxcn401a.fsf@cisco.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.91 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2100
Lines: 43


 > This can be implemented as a tracer or trace events, though I'm
 > not sure if it can fully meet your requirements or not.
 > 
 > To implement it as trace events, we add tracepoints in mmu_inlivadate_xxx(),
 > and define some TRACE_EVENT() macros.
 > 
 > And below shows how to use it:
 > 
 >   # mount -t debugfs xxx /mnt
 >   # cd /mnt/tracing/
 >   # echo 1 > events/mmu/enable
 >   # echo '(start >= 10000000 && end <= 10004096) || \
 > 	(start >= 20000000 && end <= 20004096)' > events/mmu/filter
 >   # cat trace_pipe
 >         bash-2066  [001]   795.239077: mmu_invalidate_range_start: start=10000000 end=10000100
 >         bash-2066  [001]   795.239091: mmu_invalidate_range_start: start=10000000 end=10000100
 >         bash-2066  [001]   795.239098: mmu_invalidate_range_start: start=10000000 end=10000100
 >          cat-2189  [001]   795.239502: mmu_invalidate_page: start=20000000 end=20003000
 >          cat-2189  [001]   795.239578: mmu_invalidate_page: start=20000000 end=20003000
 >         bash-2066  [001]   795.239626: mmu_invalidate_page: start=20000000 end=20003000
 > 
 > The patch is extremely simple:

Thanks... unfortunately I don't think this really helps for the use case
I'm trying to address.  What's desired is a way for an unprivileged
userspace process to monitor (parts of) its own address space; I think
getting a single stream of all such events is not going to be helpful,
because, first, the overhead of filtering out the subset of useful
events may be too high to make this useful and, second, exposing events
about unrelated processes is probably a security hole (eg "allocation
channel" attacks on crypto processes analogous to timing channel attacks)

If there were some way for each process to get a trace of its own events
then that would be very close to what I'm trying to implement.

Thanks,
  Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/