From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751502AbdGZTjM (ORCPT ); Wed, 26 Jul 2017 15:39:12 -0400 Received: from mail-io0-f194.google.com ([209.85.223.194]:38478 "EHLO mail-io0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750867AbdGZTjK (ORCPT ); Wed, 26 Jul 2017 15:39:10 -0400 From: Vince Weaver X-Google-Original-From: Vince Weaver Date: Wed, 26 Jul 2017 15:39:01 -0400 (EDT) X-X-Sender: vince@macbook-air To: linux-kernel@vger.kernel.org cc: Andy Lutomirski , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Stephane Eranian Subject: perf: bug in rdpmc/mmap accounting after exec Message-ID: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello so one last bug found by the PAPI testsuite. This one involves the rdpmc auto-disable on last unmap of an event feature. Failing test case: fd=perf_event_open(); addr=mmap(fd); exec() // without closing or unmapping the event fd=perf_event_open(); addr=mmap(fd); rdpmc() // GPFs due to rdpmc being disabled I won't pretend to be able to follow the rdpmc disabling code, but if I add some printks it looks like current->mm->context.perf_rdpmc_allowed isn't properly being reset on exec? In fact, current->mm->context.perf_rdpmc_allowed goes negative which seems like it shouldn't happen? Anyway, a test case for this can be found in the perf_event_tests, tests/rdpmc/rdpmc_exec_papi Vince