Re: + mm-remove-struct-mm_struct-exe_file-et-al.patch added to -mmtree

[Alexey Dobriyan]

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@xxxxxxxxx>
> > >
> > > 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/