lkml.org 
[lkml]   [2018]   [Jun]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: perfmon trouble
On Mon, Jun 11, 2018 at 11:51:34AM -0700, Stephane Eranian wrote:

> Thanks Al for the careful analysis. If I understand correctly, the
> problem seems to be that on
> execve the mapping of the sampling buffer is not destroyed and then on
> close, the kernel
> unmaps whatever the new binary had in that address range. The fix
> would be to ensure
> the mmap is destroyed on execve.

mmap *is* destroyed on execve; it's just that perfmon doesn't notice and
then tries to destroy it again on close, nevermind that it's a different
process, different mapping, etc.

> My problem is that I do not have IA64 hw anymore, so whatever the fix,
> I will not be able
> to test this. In the meantime, I agree with Matthew, simply disable
> PERFMON support.

Out of curiosity - what happened to never-went-into-mainline rewrite
of perfmon circa 2008? perfmon2 sourceforget site has a collection
of those, up to 2.6.29; AFAICS, they did have a somewhat saner syscall
interface (no auto-mmap on creation, no auto-munmap attempts on close).
By this point it obviously would've been too late to resurrect anyway,
but I wonder what happened with it...

\
 
 \ /
  Last update: 2018-06-11 22:06    [W:0.127 / U:0.144 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site