Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp4488086imm; Mon, 11 Jun 2018 13:13:08 -0700 (PDT) X-Google-Smtp-Source: ADUXVKLU/aoDjmZgowdbhnxT/JBNRhZN2RDyLGsVAuqL6FA/Oz7KJ/eV8Kxnw5rdv7JjO41BnO6Z X-Received: by 2002:a17:902:ac89:: with SMTP id h9-v6mr613314plr.311.1528747988585; Mon, 11 Jun 2018 13:13:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528747988; cv=none; d=google.com; s=arc-20160816; b=UcZXS/E1QidT5gaV3Ksx/kxMJx3x4u9VR/XkEEFbIi0gUOoncm98CkNtQZOgEI1jx2 Q+5U0Ply4F9XDLTIMbCUA5ZRxO3CGqRCCD48/8H193Pz2FRdkW6EytSCu3j3DB6DmH+Y 2i7L+N40lqjd5Ezx2AKYcMWQNdmt42/xvNQxAzJ4b57Frx518RXNgltEdDVljqnyM3Am ELDlkqyICiy0lzA1/AB/R581Ham7PB+lIJHCWK/eAQJp7+SQBSoPAOzGzmxlW4isvsWP 21auLeqfqku0qAyZXB2H7oX9u97ePc95TTF3kwJfgzfYBFM0TeM3tKgdVpeu/7WIXGQb 6wOQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=PXewXDYM8ueH6Rre9Jzjxt/fcUbnfqs5of7W4LX3uGo=; b=gjHXDDCRb+D6i5TQT8czBThPuNZZzqYn89UEsIK8syU8JR55xnYvl9pTb4x4UXknE2 Gcd2BKctiUJmoGcq6wsseOdwatFYhuOcA+igTeSiN5/UPfLrmeuBWuBFQzGPrMbTe9bX uQMN2FsM0u43ZQhWqQh0NkekX8rBmbL72w2aHnl2em3a0XYAHAHJfAJn2lwvksfV8Bcw bnUGdTJeFnEG3/BUpXwMj/4emj42dQVd3Yv2KEF6YgIp7aaWyMhapwZZ51d+qC0oE8sC HfF5jEv5O5ncE3siQ0eoHeJR9VJFMA7vAbVFT3Y4V1OG4wcxcN4DFpn545ESU1uu7SPs 4ijg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w12-v6si62855091pld.367.2018.06.11.13.12.54; Mon, 11 Jun 2018 13:13:08 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754122AbeFKUGL (ORCPT + 99 others); Mon, 11 Jun 2018 16:06:11 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:35744 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753786AbeFKUGK (ORCPT ); Mon, 11 Jun 2018 16:06:10 -0400 Received: from viro by ZenIV.linux.org.uk with local (Exim 4.87 #1 (Red Hat Linux)) id 1fST4j-0005qZ-Sy; Mon, 11 Jun 2018 20:06:01 +0000 Date: Mon, 11 Jun 2018 21:06:01 +0100 From: Al Viro To: Stephane Eranian Cc: willy@infradead.org, Linus Torvalds , hch@infradead.org, LKML , linux-fsdevel@vger.kernel.org, "Luck, Tony" , Fenghua Yu , linux-ia64@vger.kernel.org Subject: Re: perfmon trouble Message-ID: <20180611200601.GW30522@ZenIV.linux.org.uk> References: <20180608184842.GD30522@ZenIV.linux.org.uk> <20180609051051.GF30522@ZenIV.linux.org.uk> <20180609155107.GH30522@ZenIV.linux.org.uk> <20180611021028.GT30522@ZenIV.linux.org.uk> <20180611162313.GA6942@infradead.org> <20180611164859.GA28292@bombadil.infradead.org> <20180611171811.GB28292@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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...