From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2A506C433FE for ; Fri, 14 Oct 2022 09:41:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230131AbiJNJlB (ORCPT ); Fri, 14 Oct 2022 05:41:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58862 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230126AbiJNJk7 (ORCPT ); Fri, 14 Oct 2022 05:40:59 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BDAD95300D; Fri, 14 Oct 2022 02:40:55 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id A6AD3B822A2; Fri, 14 Oct 2022 09:40:54 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1B061C43143; Fri, 14 Oct 2022 09:40:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1665740453; bh=AncuZXGLT2khpBBT4J1GOXDx/f4gLmzsl4pImnV0mo4=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=AfG6aqIZ0bDgkg9n+xvPg19glPTnvvS2zpoq3nY73tIkS3Q/ta6wBFyk8HvGHSxdN FcTNfjg6IIchxl3B8kUbEpeR0SN6v34KZhY+n6nj0ZhNndF1VE0B22xdwKtGlny3CS 6ZNi2FwJ/Vig88OLGblWSS5xYm7dBLIrLcbInVIqath+EJvGknnm1ThrkdKHH14eoA DZH1q/W6w7eBe/z5uwC3xHQX1gqu+IaXaRdaCZpy6m6qFVpYoNgYUbIPzYWIwTcnHD dhWMFmi5VJJKt3XZHPgNPJHNrhV9EZ01ecVsRzbBpvH8wiKUEx0VylxKQselb5/bCf uKu5zZspB2ASA== Received: by mail-lf1-f45.google.com with SMTP id b1so6352390lfs.7; Fri, 14 Oct 2022 02:40:53 -0700 (PDT) X-Gm-Message-State: ACrzQf1CGEwlBJLeUSeXRBVZDOAvFw9a3a+JScJJgphVTo/ztERbFWrn bzvCeHKonNK3CstTm7IX31g3TzaKDpB5o/R3XjA= X-Google-Smtp-Source: AMsMyM7qjZ3CZSPyze/S46oOGpxLxLLOdR2le548sw16cpjxD43ujYyF+tssFYA6iJm2BupjSNvcTEqVicplpQT1fBc= X-Received: by 2002:a05:6512:3119:b0:4a2:d749:ff82 with SMTP id n25-20020a056512311900b004a2d749ff82mr1498182lfb.637.1665740451016; Fri, 14 Oct 2022 02:40:51 -0700 (PDT) MIME-Version: 1.0 References: <20221010023559.69655-1-justin.he@arm.com> <20221010023559.69655-7-justin.he@arm.com> In-Reply-To: From: Ard Biesheuvel Date: Fri, 14 Oct 2022 11:40:39 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v8 6/7] apei/ghes: Use unrcu_pointer for cmpxchg To: Borislav Petkov Cc: Peter Zijlstra , Huang Ying , Justin He , Len Brown , James Morse , Tony Luck , Mauro Carvalho Chehab , Robert Richter , Robert Moore , Qiuxu Zhuo , Yazen Ghannam , Jan Luebbe , Khuong Dinh , Kani Toshi , "linux-acpi@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-edac@vger.kernel.org" , "devel@acpica.org" , "Rafael J . Wysocki" , Shuai Xue , Jarkko Sakkinen , "linux-efi@vger.kernel.org" , nd , kernel test robot Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org On Thu, 13 Oct 2022 at 19:42, Borislav Petkov wrote: > > On Thu, Oct 13, 2022 at 06:45:44PM +0200, Peter Zijlstra wrote: > > Borislav is thinking too much x86. Failed cmpxchg() does indeed not > > imply any memory ordering for all architectures -- and while the memory > > clobber (aka. barrier()) is equivalent to an smp_wmb() on x86, that most > > certainly doesn't hold for non x86 code. > > Right, but the patch was addied by an Intel person, CCed: > > 152cef40a808 ("ACPI, APEI, GHES, Error records content based throttle")a > > So I don't think he was thinking about ARM when doing that. > > And that commit message doesn't say one whit why that memory barrier is > needed there. > > Reading that comment, it sounds like he wanted a hw memory barrier - > MFENCE - but I don't see how normal data dependency wouldn't enforce the proper order > already... > > So that barrier looks out of place there. > The cache struct pointer should not be published until after the struct itself is fully populated. So on the producer side, some kind of hardware barrier is definitely needed, or the struct may appear half-baked to other cores that can read the updated pointer. But as Peter points out, cmpxchg() itself has the required barrier semantics already, so the separate smp_wmb() is likely unnecessary. And as I suggested earlier, a full barrier is not necessary so we could relax this to cmpxchg_release() if desired. OTOH the code seems to be working fine as is, so why modify it at all? (apart from the purely cosmetic changes) > Btw, this is the next perfect example why I'm asking people to write > proper commit messages so that when we do git archeology later, we can > figure out why something was done the way it has been. > > And in this case, we can't. ;-\ > > Because writing proper commit messages is for losers. Yeah, right. > Yeah, agree there.