linux-kernel - Re: [PATCH 10/11] maps3: add /proc/kpagecount and /proc/kpageflags interfaces

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 15 Oct 2007 18:11:06 -0500
From:	Matt Mackall <mpm@...enic.com>
To:	Dave Hansen <haveblue@...ibm.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org,
	Rusty Russell <rusty@...tcorp.com.au>,
	Jeremy Fitzhardinge <jeremy@...p.org>,
	David Rientjes <rientjes@...gle.com>,
	Fengguang Wu <wfg@...l.ustc.edu.cn>
Subject: Re: [PATCH 10/11] maps3: add /proc/kpagecount and /proc/kpageflags interfaces

On Mon, Oct 15, 2007 at 03:48:33PM -0700, Dave Hansen wrote:
> On Mon, 2007-10-15 at 17:26 -0500, Matt Mackall wrote:
> > From: Matt Mackall <mpm@...enic.com>
> > 
> > This makes physical page map counts available to userspace. Together
> > with /proc/pid/pagemap and /proc/pid/clear_refs, this can be used to
> > monitor memory usage on a per-page basis.
> ...
> > +       while (count > 0) {
> > +               ppage = pfn_to_page(pfn++);
> > +               if (!ppage)
> > +                       pflags = 0;
> > +               else
> > +                       pflags = ppage->flags;
> > +
> 
> This one makes me worry a little bit.  Are we sure that this won't
> expose a wee bit too much to userspace?
> 
> I can see it making sense to clear the page refs, then inspect whether
> the page has been referenced again.  But, I worry that people are going
> to start doing things like read NUMA, SPARSEMEM, or other internal
> information out of these.

Hmm, I would have thought you'd find the NUMA bits especially interesting.
Being able to, say, colorize a process' memory map by what nodes its
pages land on could be very telling.

> I've seen quite a few patches lately that do creative things with these
> *cough*clameter*cough*, and I worry that they're too fluid to get
> exposed to userspace.

That is a concern. In general, I think getting too cute with page
flags and struct page in general is a bad idea because the rules here
are already so complex/fragile/confusing/underdocumented, but there's
definitely a lot of pressure in that direction.

> Could we just have /proc/kpagereferenced?  Is there a legitimate need
> for other flags to be visible?

Referenced, dirty, uptodate, lru, active, slab, writeback, reclaim,
and buddy all look like they might be interesting to me from the point
of view of watching what's happening in the VM graphically in
real-time.

For instance, watching the slab bit I can watch a 'find /' fill up
huge swaths of contiguous dcache memory, then get fragmented to hell
and never recover when I do a large userspace malloc. In other words,
this thing actually lets you see all the crap that happens in the VM
that we usually handwave about.

-- 
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/