linux-kernel - Re: [RFC][PATCH] proc: export more page flags in /proc/kpageflags

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: <20090416035443.GH14687@one.firstfloor.org>
Date:	Thu, 16 Apr 2009 05:54:43 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Wu Fengguang <fengguang.wu@...el.com>
Cc:	Andi Kleen <andi@...stfloor.org>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>
Subject: Re: [RFC][PATCH] proc: export more page flags in /proc/kpageflags

On Thu, Apr 16, 2009 at 10:41:33AM +0800, Wu Fengguang wrote:
> On Wed, Apr 15, 2009 at 09:57:49PM +0800, Andi Kleen wrote:
> > > That's pretty good separations. I guess it would be convenient to make the
> > > extra kernel flags available under CONFIG_DEBUG_KERNEL?
> > 
> > Yes.
> > 
> > BTW an alternative would be just someone implementing a suitable
> > command/macro in crash(1) and tell the kernel hackers to run that on
> > /proc/kcore. That would have the advantage to not require code.
> 
> Hmm, that would be horrible to code/maintain. i

Actually the bits are enums and crash is able to read C type 
information.

> One major purpose of
> /proc/kpageflags is to export the unstable kernel page flag bits as
> stable ones to user space. 

That's the first case ("administrator"), but not the second one
("kernel hacker")

BTW not saying that crash is the best solution for this, but
it's certainly an serious alternative for the kernel hacker
case. 

> Note that the exact internal flag bits can
> not only change slowly with kernel versions, but more likely with
> different kconfig combinations.

Really? The numbers should be the same, at least for a given
architecture with 32bit/64bit.

> Followed are their detailed locations. Did we found a bug? ;-)

I think all pages > 0 in a larger page are tails.  But I don't
claim to understand all the finer details of compound pages.

-Andi

--
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/