linux-kernel - Re: + mm-remove-struct-mm_struct-exe_file-et-al.patch added to -mm tree

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]

Date:	Wed, 1 Apr 2009 05:13:44 +0400
From:	Alexey Dobriyan <adobriyan@...il.com>
To:	Matt Helsley <matthltc@...ibm.com>
Cc:	Oleg Nesterov <oleg@...hat.com>, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org, dhowells@...hat.com,
	ebiederm@...ssion.com, hch@....de
Subject: Re: + mm-remove-struct-mm_struct-exe_file-et-al.patch added to -mm
	tree

On Tue, Mar 31, 2009 at 05:32:23PM -0700, Matt Helsley wrote:
> On Tue, Mar 31, 2009 at 04:40:51PM +0200, Oleg Nesterov wrote:
> > s/mm-commits/lkml/
> > 
> > On 03/30, Andrew Morton wrote:
> > >
> > > From: Alexey Dobriyan <adobriyan@...il.com>
> > >
> > > Commit 925d1c401fa6cfd0df5d2e37da8981494ccdec07 ("procfs task exe
> > > symlink").  introduced struct mm_struct::exe_file and struct
> > > mm_struct::num_exe_file_vmas.
> > >
> > > The rationale is weak: unifying MMU and no-MMU version of /proc/*/exe
> > > code.  For this a) struct mm_struct becomes bigger, b) mmap/munmap/exit
> > > become slower, c) patch adds more code than removes in fact.
> > >
> > > ->exe_file maybe well defined, but doesn't make sense always.  After
> > > original executable is unmapped, /proc/*/exe will still report it and,
> > > more importantly, pin corresponding struct file.
> > 
> > I never liked the change which introduced mm->exe_file, so I vote for
> > this patch.
> > 
> > But, as a advocatus diaboli... There was anotrher reason for ->exe_file,
> > iirc.
> > 
> > bprm->file->f_op->mmap() can change vma->vm_file, this means proc_exe_link()
> > can report the "wrong" path. The original file is not pinned in this case.
> > 
> > Matt?
> 
> That's _my_ reason for it. However no mainline code does that and hence it was
> not the reason Andrew accepted it.
> 
> I still prefer ->exe_file because I think it's a win not to walk the
> VMAs with mmap sem when doing a readlink on /proc/*/exe.

readlink on /proc/*/exe is rare, so nobody cares. ps(1) and top(1) here
don't readlink it, e. g. Number of vmas is usually small enough and, as
was mentioned, file is mapped low, so it'd be among the first VMAs.

> It's also less sensitive to the order in which VMAs appear should that ever
> change.
--
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/