Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753051AbbHDSMA (ORCPT ); Tue, 4 Aug 2015 14:12:00 -0400 Received: from mga14.intel.com ([192.55.52.115]:30545 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752060AbbHDSLo (ORCPT ); Tue, 4 Aug 2015 14:11:44 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.15,610,1432623600"; d="scan'208";a="535956008" From: "Liang, Kan" To: Andy Lutomirski CC: Thomas Gleixner , "linux-kernel@vger.kernel.org" , "H. Peter Anvin" , "Andrew Lutomirski" , Linus Torvalds , Peter Zijlstra , "Ingo Molnar" , "linux-tip-commits@vger.kernel.org" Subject: RE: [tip:perf/core] perf/x86: Add an MSR PMU driver Thread-Topic: [tip:perf/core] perf/x86: Add an MSR PMU driver Thread-Index: AQHQzpQ65l/Dz0xJ8EeCrMA8u7d3Np37ZoGAgACIDlD//60vAIAAhnPA Date: Tue, 4 Aug 2015 18:11:28 +0000 Message-ID: <37D7C6CF3E00A74B8858931C1DB2F077018D206A@SHSMSX103.ccr.corp.intel.com> References: <1437407346-31186-1-git-send-email-kan.liang@intel.com> <37D7C6CF3E00A74B8858931C1DB2F077018D16F1@SHSMSX103.ccr.corp.intel.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id t74IC5Y6003520 Content-Length: 1834 Lines: 55 > > On Tue, Aug 4, 2015 at 8:03 AM, Liang, Kan wrote: > > > >> > + > >> > +enum perf_msr_id { > >> > + PERF_MSR_TSC = 0, > >> > + PERF_MSR_APERF = 1, > >> > + PERF_MSR_MPERF = 2, > >> > + PERF_MSR_PPERF = 3, > >> > + PERF_MSR_SMI = 4, > >> > + > >> > + PERF_MSR_EVENT_MAX, > >> > +}; > >> > + > >> > +struct perf_msr { > >> > + int id; > >> > + u64 msr; > >> > +}; > >> > + > >> > +static struct perf_msr msr[] = { > >> > + { PERF_MSR_TSC, 0 }, > >> > + { PERF_MSR_APERF, MSR_IA32_APERF }, > >> > + { PERF_MSR_MPERF, MSR_IA32_MPERF }, > >> > + { PERF_MSR_PPERF, MSR_PPERF }, > >> > + { PERF_MSR_SMI, MSR_SMI_COUNT }, }; > >> > >> I think this could be easier to work with if it were [PERF_MSR_TSC] = > >> {...}, etc. No big deal, though, until the list gets long. However, > >> it might make fixing the apparent issue below easier... > >> > >> > +static int msr_event_init(struct perf_event *event) { > >> > + u64 cfg = event->attr.config; > >> > >> ... > >> > >> > + event->hw.event_base = msr[cfg].msr; > >> > >> Shouldn't this verify that the fancy enumeration code actually > >> believes that msr[cfg] exists on this system? Otherwise we might have > >> a very short wait until the perf fuzzer oopses this thing :) > >> > > > > I think we already did the check before using msr[cfg]. > > Where? All I see is: > > + if (cfg >= PERF_MSR_EVENT_MAX) > + return -EINVAL; Yes, we check cfg here. So msr[cfg] should be always available. ????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?