linux-kernel - Re: [RFC] fs, proc: Introduce the /proc/<pid>/map

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: <20110825205426.GO2803@mtj.dyndns.org>
Date:	Thu, 25 Aug 2011 22:54:26 +0200
From:	Tejun Heo <tj@...nel.org>
To:	Cyrill Gorcunov <gorcunov@...il.com>
Cc:	Vasiliy Kulikov <segoon@...nwall.com>,
	Nathan Lynch <ntl@...ox.com>,
	Oren Laadan <orenl@...columbia.edu>,
	Daniel Lezcano <dlezcano@...ibm.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Pavel Emelyanov <xemul@...allels.com>,
	linux-kernel@...r.kernel.org,
	James Bottomley <jbottomley@...allels.com>,
	LINUXFS-ML <linux-fsdevel@...r.kernel.org>,
	containers@...ts.osdl.org, Zan Lynx <zlynx@....org>,
	Andi Kleen <andi@...stfloor.org>
Subject: Re: [RFC] fs, proc: Introduce the /proc/<pid>/map_files/ directory v2

Hello,

On Thu, Aug 25, 2011 at 09:07:05PM +0400, Cyrill Gorcunov wrote:
> This will force us to bloat proc_inode a bit more, since at moment we
> have a union such as
> 
> struct proc_inode {
> 	struct pid *pid;
> 	union {
> 		int fd;
> 		unsigned long vm_start;
> 	};
> 	...
> 
> also it will require to make a buffer for names twice bigger as well.
> If all this not a problem -- then sure we can do that ;)

I'm not too familiar with this area but I don't think bloating it a
bit would be such a big problem.  proc_inode is generated on the fly
as proc directories and files are accessed, so it's not like they'll
linearly hog down more memory with increasing number of entries (sysfs
had this sort of problem in the past).

Another thing is, I don't really see why we need vm_start, or fd for
that matter, in proc_inode at all.  proc_inode is created on the fly
only as dentry gets instantiated on demand, which means we always have
d_name on hand to tell what the file is supposed to point to.  In
fact, the code already uses name_to_int() to extract fd from d_name.
Hmmm... well yeah, it actually seems that proc_inode->fd is never used
and we can simply remove it.

So, we can do the same thing w/ these mapping files too.  We just need
name_to_map_range() or something.  Also, for most address ranges, the
name sould fit inside the inline name in dentry (32 bytes on 64bit),
so it really isn't gonna bloat anything.

Thanks.

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