s/mm-commits/lkml/
On 03/30, Andrew Morton wrote:
>
> From: Alexey Dobriyan <[email protected]>
>
> 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?
Oleg.
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 <[email protected]>
> >
> > 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. It's also less
sensitive to the order in which VMAs appear should that ever change.
Cheers,
-Matt Helsley
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 <[email protected]>
> > >
> > > 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.
On 03/31, Matt Helsley wrote:
>
> On Tue, Mar 31, 2009 at 04:40:51PM +0200, Oleg Nesterov wrote:
> >
> > 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.
>
> That's _my_ reason for it. However no mainline code does that and hence it was
> not the reason Andrew accepted it.
Good.
> 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. It's also less
> sensitive to the order in which VMAs appear should that ever change.
I agree with Alexey, I don't think the VMAs walking can be a problem.
But even if it is problem, we could make a much more simple patch
to avoid it? Just add "struct path exe_path" to ->mm, no?
Oleg.
Alexey Dobriyan <[email protected]> wrote:
> and, as was mentioned, file is mapped low, so it'd be among the first VMAs.
Not so on NOMMU. The file is mapped wherever the allocator happens to throw up
a sufficient quantity of contiguous pages. It may not even be mapped in RAM.
David