linux-kernel - Re: [PATCH 0/13] maps: pagemap, kpagemap, and related cleanups

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]

Message-Id: <20070412182213.a18cc4a7.akpm@linux-foundation.org>
Date:	Thu, 12 Apr 2007 18:22:13 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Nick Piggin <nickpiggin@...oo.com.au>
Cc:	William Lee Irwin III <wli@...omorphy.com>,
	Matt Mackall <mpm@...enic.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/13] maps: pagemap, kpagemap, and related cleanups

On Fri, 13 Apr 2007 11:14:20 +1000 Nick Piggin <nickpiggin@...oo.com.au> wrote:

> Andrew Morton wrote:
> > On Fri, 13 Apr 2007 10:15:24 +1000 Nick Piggin <nickpiggin@...oo.com.au> wrote:
> 
> >>>>+               for (; i < 2 * chunk / KPMSIZE; i += 2, pfn++) {
> >>>>+                       ppage = pfn_to_page(pfn);
> >>>>+                       if (!ppage) {
> >>>>+                               page[i] = 0;
> >>>>+                               page[i + 1] = 0;
> >>>>+                       } else {
> >>>>+                               page[i] = ppage->flags;
> >>>>+                               page[i + 1] = atomic_read(&ppage->_count);
> >>>>+                       }
> >>>>+               }
> >>>
> >>>
> >>>Not a good idea to expose raw flags in this manner - it changes at the drop
> >>>of a hat.  We'd need to also expose the kernel's PG_foo-to-bitnumber
> >>>mapping to make this viable.
> >>
> >>I don't think it is viable because that makes the flags part of the
> >>userspace ABI.
> > 
> > 
> > It *will* be viable.  If the application wants to know if a page is dirty,
> > it looks up "PG_dirty" in /proc/pg_foo-to-bitnumber and uses PG_dirty's
> > numerical offset when inspecting fields in /proc/kpagemap.  If correctly
> > designed, such a monitoring application will be able to report upon page
> > flags which we haven't even thought up yet.
> 
> Ooh, you wanted a _runtime_ mapping of flags, yeah then I guess that works.
> Still seems like a basically hit and miss affair to just use flags. What if
> you want to know the process mapping a page? With systemtap or something you
> could walk the rmap structures. What if you want to look at pages along the
> LRU list rather than per-pfn? What about connecting pages to inodes?

Well hang on.  This isn't a tool for understanding kernel behaviour.  It's
a tool for understanding applciation behaviour.

So one doesn't ask "who is mapping that page" - that's a kernel developer
thing.

Instead, one says "what pages are being used by my application", then, for
each of those pages "what is that page's state".  So the first step is to
collect all the pfns from /proc/$(pidof my-application)/pagemap and then to
use those pfns to look the individual pages up in /proc/kpagemap.

If you really want to know "who is using page 123435" then you'd need to
search /proc/*/pagemap.  There are possibly legitimate reasons why an
application developer would want to at least pertially perform such an
operation ("who am I sharing with"), but I doubt if it's the common case.

> 
> But I was going to say
> that satisfying an Oracle requirement is a good reason _not_ to merge it ;)
>

hm, yes, there's plenty of precedent for that.

> (I joke!)

I akpm!
-
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/