Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752348AbdHNRwc (ORCPT ); Mon, 14 Aug 2017 13:52:32 -0400 Received: from g2t2353.austin.hpe.com ([15.233.44.26]:37144 "EHLO g2t2353.austin.hpe.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750753AbdHNRw2 (ORCPT ); Mon, 14 Aug 2017 13:52:28 -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/OMe00e0Ovda8CeGBqJzlIKAgAEZcQCAAIyugIAD9yeAgAW2iQCABSfDgIAACkUAgAAEFwCAAAdxAIAACkmA Date: Mon, 14 Aug 2017 17:52:25 +0000 Message-ID: <1502732561.2042.141.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> <1502128177.2042.131.camel@hpe.com> <20170811090414.GB9432@nazgul.tnic> <1502725671.2042.137.camel@hpe.com> <20170814162436.lta5xm742hh6g7yk@pd.tnic> <1502728754.2042.139.camel@hpe.com> <20170814170552.j3lhzvnwlpz75y4g@pd.tnic> In-Reply-To: <20170814170552.j3lhzvnwlpz75y4g@pd.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.211.195.8] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;DF4PR84MB0185;6:tkrxYqEcghDH9dASfF8dBNlXJ8wyv//ueR3r1EM5D1l8UjMBHrtKYNhlPm/ML7Vwe9pKGbY0Zcemibow5JKBjWCtAyOJWcMb0LqCvKBjs3gA0BuinmPxDYj/koNVj1eZ/WZfklxg1MXZ5YkfzgtoDLP5MxzdoJwHu6BknQPwR4sFxYTIrWLgbanUUwN/VCfWCBZ1/oxUgeIfwXLSVqAqpYJvIe3wzBNsTLDjNQLfrraCEtckcWI0U286IcQJeCoN+oMln46rt6vGTpMBfTfrwDcZpH/yfvB/Ngre/rAj66EONDZCilwAwDAQj/iyEIm/BzuTVUBaGBs+7iBYzmTqHg==;5:kKJBX7weJpT/l+vRZVcdVzXJtfeEq1pO+rVVvOdQY7j28Rnemdfucb/q/TUyY+fcLJHyt7uy/8/0y7x+Dltwb73xK8uWfBsDGkM7I0XmDaw44XjXeTQqYzpd8PyUvsrBycvRAxUmOiyB/+Zb2+MMgw==;24:MiWwUJZpJhdB/VRxdEj4E6rEAhVVc5U6Dsz7146ShgHjBMLRCNDh4pwIWqeC8lIeLKxRgQBjen4hFWz/Zu1K/ui/nd5vRS4xpZ29T+Q7oEg=;7:r9iqbm+nXRZqx7u2klUMvIwDRishPWYnsCxgD/nVWiBi2iMFV76K/ytCVU5unJtkZDnw3dAlJ/U6g46w79EZGDps+YepZmyc3pQ5Ndu+60JWug01SgmD9GNggU3WyqO0u6pr1JW38yuvelBD7TyVv0YuoFY+yUEU/r4ovEX/gdpVN6JBw7EBBVoL64cXdHvvPXmRVCBcriHn/tG3vYjqB/oK7TodrqUOWJAOoLYVULo= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 036c3a74-ab7f-4ac3-f957-08d4e33d3918 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095);SRVR:DF4PR84MB0185; x-ms-traffictypediagnostic: DF4PR84MB0185: 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)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123560025)(20161123558100)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095);SRVR:DF4PR84MB0185;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:DF4PR84MB0185; x-forefront-prvs: 039975700A x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(39860400002)(377424004)(189002)(24454002)(199003)(68736007)(478600001)(8936002)(6506006)(2906002)(3660700001)(86362001)(105586002)(14454004)(25786009)(81166006)(229853002)(5660300001)(305945005)(8676002)(7736002)(1730700003)(6916009)(2950100002)(3846002)(102836003)(6116002)(2501003)(3280700002)(6486002)(6436002)(81156014)(77096006)(66066001)(103116003)(6512007)(189998001)(50986999)(101416001)(76176999)(54356999)(36756003)(33646002)(106356001)(54906002)(93886004)(97736004)(5640700003)(110136004)(2900100001)(2351001)(53936002)(4326008)(6246003);DIR:OUT;SFP:1102;SCL:1;SRVR:DF4PR84MB0185;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: MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Aug 2017 17:52:25.5593 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc X-MS-Exchange-Transport-CrossTenantHeadersStamped: DF4PR84MB0185 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 v7EHqcOL024119 Content-Length: 917 Lines: 26 On Mon, 2017-08-14 at 19:05 +0200, Borislav Petkov wrote: > On Mon, Aug 14, 2017 at 04:48:57PM +0000, Kani, Toshimitsu wrote: > > Right, but the issue is how [ghes_edac_]report_mem_error() protects > > from possible concurrent calls from multiple GHES sources when > > there is only a single mci. > > Do you know of an actual firmware reporting multiple errors > concurrently? I do not know. We have multiple GHES entries, but they all use SCI. Since ACPICA uses a single threaded workqueue for notify handlers, they are serialized among SCIs. ACPI 6.2 defines multiple notification types in Table 18-383, and ghes_proc() can be called from ghes_poll_func(), ghes_irq_func(), and ghes_notify_sci(). So, I think it is safe to operate per an entry basis. > GHES v2 even needs to ACK the current error first before it can read > the next one. Yes, but this ACK is done per a GHES entry as well. Thanks, -Toshi