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...
