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 for Android: free password hash cracker in your pocket

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

Date:	Mon, 11 May 2009 11:31:57 -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 Mon, 11 May 2009 13:45:54 +0200
Ingo Molnar <mingo@...e.hu> wrote:

> > Yes, we could place pagemap's two auxiliary files into debugfs but 
> > it would be rather stupid to split the feature's control files 
> > across two pseudo filesystems, one of which may not even exist.  
> > Plus pagemap is not a kernel debugging feature.
> 
> That's not what i'm suggesting though.
> 
> What i'm suggesting is that there's a zillion ways to enumerate and 
> index various kernel objects, doing that in /proc is fundamentally 
> wrong. And there's no need to create a per PID/TID directory 
> structure in /debug either, to be able to list and access objects by 
> their PID.

The problem with procfs was that it was growing a lot of random
non-process-related stuff.  We never deprecated procfs - we decided
that it should be retained for its original purpose and that
non-process-realted things shouldn't go in there.

The /proc/<pid>/pagemap file clearly _is_ process-related, and
/proc/<pid> is the natural and correct place for it to live.

Yes, sure, there are any number of ways in which that data could be
presented to userspace in other locations and via other means.  But
there would need to be an extraordinarily good reason for violating the
existing paradigm/expectation/etc.

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