From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751967AbdHGR7V (ORCPT ); Mon, 7 Aug 2017 13:59:21 -0400 Received: from g9t5009.houston.hpe.com ([15.241.48.73]:38464 "EHLO g9t5009.houston.hpe.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751820AbdHGR7S (ORCPT ); Mon, 7 Aug 2017 13:59:18 -0400 From: "Kani, Toshimitsu" To: "bp@alien8.de" CC: "linux-acpi@vger.kernel.org" , "lenb@kernel.org" , "mchehab@kernel.org" , "tony.luck@intel.com" , "linux-kernel@vger.kernel.org" , "linux-edac@vger.kernel.org" , "rjw@rjwysocki.net" Subject: Re: [PATCH v2 4/7] ghes_edac: avoid multiple calls to dmi_walk() Thread-Topic: [PATCH v2 4/7] ghes_edac: avoid multiple calls to dmi_walk() Thread-Index: AQHTDKTuWyxK/OMe00e0Ovda8CeGBqJzlIKAgAEZcQCAAIyugIAD9yeA Date: Mon, 7 Aug 2017 17:59:15 +0000 Message-ID: <1502128177.2042.131.camel@hpe.com> References: <20170803215753.30553-1-toshi.kani@hpe.com> <20170803215753.30553-5-toshi.kani@hpe.com> <20170804040525.GE12082@nazgul.tnic> <1501879964.2042.117.camel@hpe.com> <20170805051615.GC23214@nazgul.tnic> In-Reply-To: <20170805051615.GC23214@nazgul.tnic> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=toshi.kani@hpe.com; x-originating-ip: [15.219.163.8] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;DF4PR84MB0186;6:hi0q0LgjT40Sm5qN3IeD+06bng7oNWhQVEDZfnWaRDX1mtN6+PGMqyFsS/kyOmdC0jvMic1VUpjPfr3XJECFp57j/WEsjKfMyw4XxJgfuAWTnxJZM3OSft48fUck271vhhaxoYkoEUco80sSMx0tHDMRMXqI+YT+a3YqnR4vAkMBHPiXETKpXZF+iRq72jMLAoggOuqCXHCQeP5PSQ3x631sfmG97kISXwKQPg1lBseMzBBsvQCP3iCZYehpRmfu44ZSbSsKA/k0ZmCqflry4sB2je/0USmNyTQmSgqWeFb0DZm73tRgFai1NRyKcZPFwrXsyLSfy62P9BBqo0BdsQ==;5:5/hsVf460lZ214n5RNKgIMK8bq0CA2TpaOEUiLorwN6jd+Syy/BMuRaLzAw4WmYFXTtcBb/9BTkncXU50nUtwMRvdbnPvhFr4Tk0MaW+U1181yPr532YGaaz8Z9MRwUebLtcgy0wD023qMMjCFHCiA==;24:EEPvGrlmm6JCA80ztCjSP8KvvKH7BHbZ9okBENXLEfiofU4PWsTJCPQ8qBb5aQ2x2Z4RMoxMVRG8Ta5OOB03j9WmgIigYysEbcekkHmT2rs=;7:sKsxq/i2UH/Q7CcSJfR4qMDcwu5BVpHYM6AtEd6F1cw8hGdyYaeqNaZQ6xJZxzyDMKFJ2ekInmV3GvPgu4quUk8Y/QA0qAe/Y0ywcTbBqsL1w/Srz1QGbJu15Pj5TUODWLN6C38cNsJXQqYT+ztRGqJ2mVfie+3fpWHYV+HA6piUOEVxF2292t42LmudtXYYv9s74/st9ccm6f6GRYL3JwlLJinlJ3D9bB8hxwkLlb0= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 8bdee47f-8de5-4038-f795-08d4ddbe0474 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095);SRVR:DF4PR84MB0186; x-ms-traffictypediagnostic: DF4PR84MB0186: x-exchange-antispam-report-test: UriScan:(211171220733660); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(20161123555025)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095);SRVR:DF4PR84MB0186;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:DF4PR84MB0186; x-forefront-prvs: 0392679D18 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(39410400002)(39400400002)(39850400002)(39840400002)(39860400002)(39450400003)(189002)(24454002)(377424004)(199003)(6486002)(77096006)(305945005)(6512007)(50986999)(5660300001)(6506006)(54356999)(76176999)(93886004)(101416001)(4326008)(8676002)(81156014)(6436002)(5640700003)(81166006)(54906002)(1730700003)(8936002)(66066001)(6916009)(478600001)(2900100001)(68736007)(2950100002)(25786009)(7736002)(2906002)(14454004)(36756003)(2501003)(229853002)(33646002)(103116003)(106356001)(6246003)(105586002)(53936002)(189998001)(97736004)(38730400002)(3660700001)(110136004)(102836003)(3846002)(3280700002)(6116002)(2351001)(86362001);DIR:OUT;SFP:1102;SCL:1;SRVR:DF4PR84MB0186;H:DF4PR84MB0187.NAMPRD84.PROD.OUTLOOK.COM;FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <260B6D54D552984C9453CA3D41346493@NAMPRD84.PROD.OUTLOOK.COM> MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Aug 2017 17:59:15.3444 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc X-MS-Exchange-Transport-CrossTenantHeadersStamped: DF4PR84MB0186 X-OriginatorOrg: hpe.com 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 nfs id v77HxRqa025264 On Sat, 2017-08-05 at 07:16 +0200, Borislav Petkov wrote: > On Fri, Aug 04, 2017 at 09:02:17PM +0000, Kani, Toshimitsu wrote: > > GHES platform devices correspond to GHES entries, which define > > firmware interfaces to report generic memory errors to the OS, such > > as NMI and SCI.  These devices are associated with all DIMMs, not a > > particular DIMM. > > And? Stating the obvious brings you what exactly? > > IOW, you still haven't answered my question. Sorry about that. Let me copy your original comments to make sure I answer your questions this time. > So the problem is that ghes_edac_register() gets called multiple > times depending on how many GHES platform devices are on the system. > But yet they all scan *all* DIMMs.  Right, and this patch changes ghes_edac_register() to scan all DIMMs at the first time and do not scan them next times. > So instead you should return if > the DIMMs have been counted already and not register a second time. > Which makes that whole mc counting kinda useless. So you could rip > that out too. Oh, I see. So, ghes_edac_register() should return no-op a second time, and does not call edac_mc_add_mc() to register with a separate mci. I think we should keep the current scheme, which registers an mci for each GHES entry. ghes_edac_report_mem_error() expects that error- reporting is serialized per a GHES entry. Sharing a single mci among all GHES entries / error interfaces might lead to a race condition. Thanks, -Toshi