Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp4497275imm; Mon, 11 Jun 2018 13:24:19 -0700 (PDT) X-Google-Smtp-Source: ADUXVKLaFSZX9/SnzjYuJZ92v4HOIfW9mAi9irMjYE7rmZhWmh3W9TCEGZFuhmXpLtLrQnvEBj0T X-Received: by 2002:a17:902:bd42:: with SMTP id b2-v6mr670967plx.23.1528748659205; Mon, 11 Jun 2018 13:24:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528748659; cv=none; d=google.com; s=arc-20160816; b=eQ0zEBhch5yj9M5JmQjlelLgIQwjLCla1bkam4Vf2u/4fYG+fan+TnigiAT73E8ER5 qGlGOkJB4N1ybY5SmD/D0YrxoBQQvw5jutcTMhi8/VMB0xzv6NS5uSFt/QmoMfA3usQD UccxUqS67wJECk5Fk3B7tx/y5xMyF/c6JiM4LqWMALAJpvKZ6AeN7b8Af8sVZstLJlXJ CVuk1PylUadjRkPxbr9KWKLWpkmq/EFllhQQwsXczAHoh5oy2JcPI9CIi11d9WEprmnt OS6FSZk6SG8qhzU8SDV1kNAiyW7/RglA0opayQwpJOd7ZsC7oHUCFmBiPpOHQczu1WH5 k4AQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature :arc-authentication-results; bh=/t6TzYRrEArVifOmxTfTGnjHafv6/3KlwlFq8kwamCo=; b=bDZ3rZwM6kU1BfZw0vTa69SCuwCBljXd7FMTe7g2XmoSSEzvgtprT+5bRRc/uVlnQ6 dcvRb7eirizYht7ZxSv+Svb5h7VmCIsIwQ2Ly+LlG7unLvVyTpm8G8ZWbjUuRkb/aIoA pwhi7e0uypY1IAp+kRAoGUFG24BMizaZyKIxqXcCpQH7n6OCJ6SNJhVZCcn4g6TMyx2X 7Fr+GPV1diMCnV9tMYA3ksHMLNrMUVw1FIU01FbVVCgtx8IWYGLaTBqSSzDgMMvBcSyT zMGd8nKuT/PrYKzn85tfTHAT7R+Vn1s/URWaMlJVOF3Rm8tDmZ9MNpcDRgZ5N2+keRQH qG0g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=KW4PmawE; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b7-v6si4663066pgr.471.2018.06.11.13.24.05; Mon, 11 Jun 2018 13:24:19 -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; dkim=pass header.i=@google.com header.s=20161025 header.b=KW4PmawE; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933039AbeFKSvu (ORCPT + 99 others); Mon, 11 Jun 2018 14:51:50 -0400 Received: from mail-wm0-f65.google.com ([74.125.82.65]:53030 "EHLO mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932081AbeFKSvs (ORCPT ); Mon, 11 Jun 2018 14:51:48 -0400 Received: by mail-wm0-f65.google.com with SMTP id p126-v6so16464254wmb.2 for ; Mon, 11 Jun 2018 11:51:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/t6TzYRrEArVifOmxTfTGnjHafv6/3KlwlFq8kwamCo=; b=KW4PmawEh+abKnolb2EX+ByOQ7+b2Z+94ZMAJT0di9sPGivYRSylNXMmpiHe4ZekpJ 17k4mMzWQOd0VSPOXymvc5MFhML/9NOQyBIKZzGRqGgteT9iNExh99Vh/lK3XBVRl/aM liUmeeLBCVBZ68FLb4+XopAHwufNfI/Kc5LORv0bGSif+bqYtBVy/TE2MTluc6LQ4hQL zqrILgW2n7eJfsFCeth1kf6bHEkq1pY+70DJpuHfvXYQYawRk621l4hyk1oV+c8nmLGl ylv0ztALWFSFwGrqesuY4W6nu5ihuwfvq+WxS330RbygvuVYZTOIOjAqDX9dvKxKWgu9 mIKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/t6TzYRrEArVifOmxTfTGnjHafv6/3KlwlFq8kwamCo=; b=bVi3KPgQek/hxh2jloFx1fSPGc5QXrQei0u8SMNMafeM8pEu3CHEY3HQjKW3CRMSTk SEvByvaFFVXlvYFhW+fvZgnc+sCXIXrqKlj3S4knMOPJIrNDAvX5ZYP41GakV2HolyPT jo/bresd+KY87rjHO2nmcYsPy0rQElsbVBCUQNSvwP8DPkLx91YFeJGk5bg6f6+/LSaX 2kYUcX7dHoKEFPShWHAZlDjyA191y0KnftcWAHw65xt873qQb832UQfRgppIG5N41mtp Ak79DFJtEHhOpnZdRtP1brPJS2xrGvlCV7+JOMELLjy01a4M6XVun8Jg+jN5s7+NbNyK l1mw== X-Gm-Message-State: APt69E0hxY7JU2IivbsaV9GNuXaSensL7WZ9bdsAbryCKyJVfSEGfrLa K2T8u/p3eIn9x6Tz3asWR3K9o7ZcINmv30/EuiOguw== X-Received: by 2002:a1c:afc3:: with SMTP id y186-v6mr84085wme.87.1528743106721; Mon, 11 Jun 2018 11:51:46 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: <20180611171811.GB28292@bombadil.infradead.org> From: Stephane Eranian Date: Mon, 11 Jun 2018 11:51:34 -0700 Message-ID: Subject: Re: perfmon trouble To: willy@infradead.org Cc: Linus Torvalds , hch@infradead.org, Alexander Viro , LKML , linux-fsdevel@vger.kernel.org, "Luck, Tony" , Fenghua Yu , linux-ia64@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Mon, Jun 11, 2018 at 10:18 AM Matthew Wilcox wrote: > > On Mon, Jun 11, 2018 at 10:04:00AM -0700, Linus Torvalds wrote: > > On Mon, Jun 11, 2018 at 9:49 AM Matthew Wilcox wrote: > > > > > > The problem is that even oprofile on ia64 depends on perfmon. > > > > Hmm? You can definitely enable ia64 support for oprofile even without perfmon. > > Oh, I think my memory is playing tricks on me. This is my confusion, I think: > > oprofile-$(CONFIG_PERFMON) += perfmon.o > > so perfmon events are exposed through oprofile, but you can disable > perfmon without disabling oprofile. > > > Because I'd be inclined to just remove CONFIG_PERFMON support, and see > > if anybody even notices.. > > > > I'm not expecting a lot of people to do a lot of oprofile on ia64 > > anyway. It's a bit late to start optimizing things now. > > > > Do people use perfmon still? Maybe. Maybe not. Perhaps we could just > > mark it as broken in the Kconfig file for now, and see if somebody > > says something? > 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. 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. thanks. > That gets my vote. > > Tony? Fenghua? > > diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig > index 792437d526c6..ff861420b8f5 100644 > --- a/arch/ia64/Kconfig > +++ b/arch/ia64/Kconfig > @@ -455,6 +455,7 @@ config IA64_MCA_RECOVERY > > config PERFMON > bool "Performance monitor support" > + depends on BROKEN > help > Selects whether support for the IA-64 performance monitor hardware > is included in the kernel. This makes some kernel data-structures a >