From: Borislav Petkov <bp@alien8.de>
To: Peter Zijlstra <peterz@infradead.org>, Huang Ying <ying.huang@intel.com>
Cc: Ard Biesheuvel <ardb@kernel.org>, Justin He <Justin.He@arm.com>,
Len Brown <lenb@kernel.org>, James Morse <James.Morse@arm.com>,
Tony Luck <tony.luck@intel.com>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Robert Richter <rric@kernel.org>,
Robert Moore <robert.moore@intel.com>,
Qiuxu Zhuo <qiuxu.zhuo@intel.com>,
Yazen Ghannam <yazen.ghannam@amd.com>,
Jan Luebbe <jlu@pengutronix.de>,
Khuong Dinh <khuong@os.amperecomputing.com>,
Kani Toshi <toshi.kani@hpe.com>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>,
"devel@acpica.org" <devel@acpica.org>,
"Rafael J . Wysocki" <rafael@kernel.org>,
Shuai Xue <xueshuai@linux.alibaba.com>,
Jarkko Sakkinen <jarkko@kernel.org>,
"linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>,
nd <nd@arm.com>, kernel test robot <lkp@intel.com>
Subject: Re: [PATCH v8 6/7] apei/ghes: Use unrcu_pointer for cmpxchg
Date: Thu, 13 Oct 2022 19:42:16 +0200 [thread overview]
Message-ID: <Y0hN+Cd8ZT1d9f7e@zn.tnic> (raw)
In-Reply-To: <Y0hAuBkmiUGfCs8/@hirez.programming.kicks-ass.net>
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.
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.</sarcasm>
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
next prev parent reply other threads:[~2022-10-13 17:42 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-10 2:35 [PATCH v8 0/7] Make ghes_edac a proper module Jia He
2022-10-10 2:35 ` [PATCH v8 1/7] efi/cper: export several helpers for ghes_edac to use Jia He
2022-10-10 2:35 ` [PATCH v8 2/7] EDAC/ghes: Add a notifier for reporting memory errors Jia He
2022-10-10 2:35 ` [PATCH v8 3/7] EDAC/ghes: Prepare to make ghes_edac a proper module Jia He
2022-10-10 2:35 ` [PATCH v8 4/7] EDAC/ghes: Make ghes_edac a proper module to remove the dependency on ghes Jia He
2022-10-10 2:35 ` [PATCH v8 5/7] EDAC: Add the ghes_get_devices() check for chipset-specific edac drivers Jia He
2022-10-10 2:35 ` [PATCH v8 6/7] apei/ghes: Use unrcu_pointer for cmpxchg Jia He
2022-10-11 10:33 ` Borislav Petkov
2022-10-11 14:32 ` Justin He
2022-10-11 14:45 ` Borislav Petkov
2022-10-12 4:35 ` Justin He
2022-10-12 12:04 ` Justin He
2022-10-13 13:37 ` Borislav Petkov
2022-10-13 15:41 ` Ard Biesheuvel
2022-10-13 16:37 ` Borislav Petkov
2022-10-13 16:45 ` Peter Zijlstra
2022-10-13 17:42 ` Borislav Petkov [this message]
2022-10-14 9:40 ` Ard Biesheuvel
2022-10-14 19:40 ` Borislav Petkov
2022-10-14 12:00 ` Justin He
2022-10-14 14:31 ` Ard Biesheuvel
2022-10-14 15:10 ` Peter Zijlstra
2022-10-14 15:24 ` Ard Biesheuvel
2022-10-17 8:47 ` Justin He
2022-10-17 9:27 ` Ard Biesheuvel
2022-10-17 11:57 ` Justin He
2022-10-13 16:41 ` Peter Zijlstra
2022-10-10 2:35 ` [PATCH v8 7/7] EDAC/igen6: Return consistent errno when another edac driver is enabled Jia He
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y0hN+Cd8ZT1d9f7e@zn.tnic \
--to=bp@alien8.de \
--cc=James.Morse@arm.com \
--cc=Justin.He@arm.com \
--cc=ardb@kernel.org \
--cc=devel@acpica.org \
--cc=jarkko@kernel.org \
--cc=jlu@pengutronix.de \
--cc=khuong@os.amperecomputing.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-edac@vger.kernel.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.com \
--cc=mchehab@kernel.org \
--cc=nd@arm.com \
--cc=peterz@infradead.org \
--cc=qiuxu.zhuo@intel.com \
--cc=rafael@kernel.org \
--cc=robert.moore@intel.com \
--cc=rric@kernel.org \
--cc=tony.luck@intel.com \
--cc=toshi.kani@hpe.com \
--cc=xueshuai@linux.alibaba.com \
--cc=yazen.ghannam@amd.com \
--cc=ying.huang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.