linux-kernel - Re: [PATCH 4/8] 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: <20090508132452.bafa287a.akpm@linux-foundation.org>
Date:	Fri, 8 May 2009 13:24:52 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	fengguang.wu@...el.com, fweisbec@...il.com, rostedt@...dmis.org,
	a.p.zijlstra@...llo.nl, lizf@...fujitsu.com,
	linux-kernel@...r.kernel.org, kosaki.motohiro@...fujitsu.com,
	andi@...stfloor.org, mpm@...enic.com, adobriyan@...il.com,
	linux-mm@...ck.org
Subject: Re: [PATCH 4/8] proc: export more page flags in /proc/kpageflags

On Fri, 8 May 2009 13:47:42 +0200
Ingo Molnar <mingo@...e.hu> wrote:

> 
> * Wu Fengguang <fengguang.wu@...el.com> wrote:
> 
> > Export all page flags faithfully in /proc/kpageflags.
> 
> Ongoing objection and NAK against extended haphazard exporting of 
> kernel internals via an ad-hoc ABI via ad-hoc, privatized 
> instrumentation that only helps the MM code and nothing else.

You're a year too late.  The pagemap interface is useful.

> /proc/kpageflags should be done via the proper methods outlined in 
> the previous mails i wrote on this topic: for example by using the 
> 'object collections' abstraction i suggested.

What's that?

> So this should be done in cooperation with instrumentation folks, 

Feel free to start cooperating.

> while improving _all_ of Linux instrumentation in general. Or, if 
> you dont have the time/interest to work with us on that, it should 
> not be done at all. Not having the resources/interest to do 
> something properly is not a license to introduce further 
> instrumentation crap into Linux.

If and when whatever-this-stuff-is is available and if it turns out to be
usable then someone can take on the task of migrating the existing
apgemap implementation over to use the new machinery while preserving
existing userspace interfaces.

But we shouldn't block improvements to an existing feature because
someone might change the way that feature is implemented some time in
the future.
--
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/