All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Zhang, Jonathan Zhixiong" <zjzhang@codeaurora.org>
To: Ingo Molnar <mingo@kernel.org>
Cc: Will Deacon <will.deacon@arm.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	"H . Peter Anvin" <hpa@zytor.com>,
	"linux-kernel @ vger . kernel . org"
	<linux-kernel@vger.kernel.org>,
	"linux-efi @ vger . kernel . org" <linux-efi@vger.kernel.org>,
	Matt Fleming <matt.fleming@intel.com>,
	Borislav Petkov <bp@suse.de>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	Matt Fleming <matt@codeblueprint.co.uk>
Subject: Re: [PATCH 2/2] acpi, apei: use appropriate pgprot_t to map GHES memory
Date: Tue, 25 Aug 2015 10:30:04 -0700	[thread overview]
Message-ID: <55DCA61C.8010109@codeaurora.org> (raw)
In-Reply-To: <20150825085923.GA22414@gmail.com>



On 8/25/2015 1:59 AM, Ingo Molnar wrote:
>
> * Zhang, Jonathan Zhixiong <zjzhang@codeaurora.org> wrote:
>
>>
>>
>> On 8/22/2015 2:24 AM, Ingo Molnar wrote:
>>>
>>> * Jonathan (Zhixiong) Zhang <zjzhang@codeaurora.org> wrote:
>>>
>>>> From: "Jonathan (Zhixiong) Zhang" <zjzhang@codeaurora.org>
>>>>
>>>> With ACPI APEI firmware first handling, generic hardware error
>>>> record is updated by firmware in GHES memory region. On an arm64
>>>> platform, firmware updates GHES memory region with uncached
>>>> access attribute, and then Linux reads stale data from cache.
>>>
>>> This paragraph *still* doesn't parse for me. It's not any English
>>> I can recognize: what is a 'With ACPI APEI firmware first handling'?
>> APEI is ACPI Platform Error Interface; it is part of ACPI spec,
>> defining the aspect of hardware error handling. "firmware first
>> handling" is a terminology used in APEI. It describes such mechanism
>> that when hardware error happens, firmware intersects/handles such
>> hardware error, formulates hardware error record and writes the record
>> to GHES memory region, notifies the kernel through NMI/interrupt, then
>> the kernel GHES driver grabs the error record from the GHES memory
>> region.
>
> Argh. So how about translating that to English and putting that misnomer into
> scare quotes, and saying something like:
>
>    If the ACPI APEI firmware handles the error first (called "firmware first
>    handling"), the generic hardware error record is updated by the firmware in the
>    GHES memory region.
>
> ( Also note all the missing articles I added for readability. The rest of the
>    changelog is missing articles as well. )
Thank you very much, Ingo. Input are taken.
>
>>> ... plus what this changelog still doesn't mention is the most important part
>>> of any bug fix description: how does the user notice this in practice and why
>>> does he care?
>>
>> The changelog mentioned that Linux would read stale data from cache. When stale
>> data is read, kernel reports there is no new hardware error when there actually
>> is.
>
> Note that this is the most valuable sentence so far, in this whole changelog and
> discussion. And we needed how many emails to get to this point?
>
> obviously saying 'stale data' in itself does not mean much - it could mean a
> harmless inconsistency nobody really cares about, or in fact it could mean
> something more serious:
Sure, makes sense.
>
>> [...] This may lead to further damage in various scenarios, such as error
>> propagation caused data corruption.
>
> Please outline this better. How users are affected in practice is far more
> important than any other detail.
Yes, will do. I just sent out an update for your review.
>
> Thanks,
>
> 	Ingo
>

-- 
Jonathan (Zhixiong) Zhang
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

WARNING: multiple messages have this Message-ID (diff)
From: "Zhang, Jonathan Zhixiong" <zjzhang-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
To: Ingo Molnar <mingo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>,
	Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>,
	"H . Peter Anvin" <hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>,
	"linux-kernel @ vger . kernel . org"
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"linux-efi @ vger . kernel . org"
	<linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Matt Fleming
	<matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	Borislav Petkov <bp-l3A5Bk7waGM@public.gmane.org>,
	Ard Biesheuvel
	<ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	Catalin Marinas <Catalin.Marinas-5wv7dgnIgG8@public.gmane.org>,
	Matt Fleming
	<matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
Subject: Re: [PATCH 2/2] acpi, apei: use appropriate pgprot_t to map GHES memory
Date: Tue, 25 Aug 2015 10:30:04 -0700	[thread overview]
Message-ID: <55DCA61C.8010109@codeaurora.org> (raw)
In-Reply-To: <20150825085923.GA22414-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>



On 8/25/2015 1:59 AM, Ingo Molnar wrote:
>
> * Zhang, Jonathan Zhixiong <zjzhang-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> wrote:
>
>>
>>
>> On 8/22/2015 2:24 AM, Ingo Molnar wrote:
>>>
>>> * Jonathan (Zhixiong) Zhang <zjzhang-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> wrote:
>>>
>>>> From: "Jonathan (Zhixiong) Zhang" <zjzhang-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>>>>
>>>> With ACPI APEI firmware first handling, generic hardware error
>>>> record is updated by firmware in GHES memory region. On an arm64
>>>> platform, firmware updates GHES memory region with uncached
>>>> access attribute, and then Linux reads stale data from cache.
>>>
>>> This paragraph *still* doesn't parse for me. It's not any English
>>> I can recognize: what is a 'With ACPI APEI firmware first handling'?
>> APEI is ACPI Platform Error Interface; it is part of ACPI spec,
>> defining the aspect of hardware error handling. "firmware first
>> handling" is a terminology used in APEI. It describes such mechanism
>> that when hardware error happens, firmware intersects/handles such
>> hardware error, formulates hardware error record and writes the record
>> to GHES memory region, notifies the kernel through NMI/interrupt, then
>> the kernel GHES driver grabs the error record from the GHES memory
>> region.
>
> Argh. So how about translating that to English and putting that misnomer into
> scare quotes, and saying something like:
>
>    If the ACPI APEI firmware handles the error first (called "firmware first
>    handling"), the generic hardware error record is updated by the firmware in the
>    GHES memory region.
>
> ( Also note all the missing articles I added for readability. The rest of the
>    changelog is missing articles as well. )
Thank you very much, Ingo. Input are taken.
>
>>> ... plus what this changelog still doesn't mention is the most important part
>>> of any bug fix description: how does the user notice this in practice and why
>>> does he care?
>>
>> The changelog mentioned that Linux would read stale data from cache. When stale
>> data is read, kernel reports there is no new hardware error when there actually
>> is.
>
> Note that this is the most valuable sentence so far, in this whole changelog and
> discussion. And we needed how many emails to get to this point?
>
> obviously saying 'stale data' in itself does not mean much - it could mean a
> harmless inconsistency nobody really cares about, or in fact it could mean
> something more serious:
Sure, makes sense.
>
>> [...] This may lead to further damage in various scenarios, such as error
>> propagation caused data corruption.
>
> Please outline this better. How users are affected in practice is far more
> important than any other detail.
Yes, will do. I just sent out an update for your review.
>
> Thanks,
>
> 	Ingo
>

-- 
Jonathan (Zhixiong) Zhang
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

  reply	other threads:[~2015-08-25 17:30 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-14 22:37 [PATCH V2 1/2] arm64: apei: implement arch_apei_get_mem_attributes() Jonathan (Zhixiong) Zhang
2015-08-14 22:37 ` Jonathan (Zhixiong) Zhang
2015-08-14 22:37 ` [PATCH 2/2] acpi, apei: use appropriate pgprot_t to map GHES memory Jonathan (Zhixiong) Zhang
2015-08-17 13:13   ` Matt Fleming
2015-08-17 13:13     ` Matt Fleming
2015-08-17 21:10     ` Zhang, Jonathan Zhixiong
2015-08-17 21:10       ` Zhang, Jonathan Zhixiong
2015-08-22  9:24   ` Ingo Molnar
2015-08-22  9:24     ` Ingo Molnar
2015-08-24 18:22     ` Zhang, Jonathan Zhixiong
2015-08-24 18:22       ` Zhang, Jonathan Zhixiong
2015-08-25  8:59       ` Ingo Molnar
2015-08-25  8:59         ` Ingo Molnar
2015-08-25 17:30         ` Zhang, Jonathan Zhixiong [this message]
2015-08-25 17:30           ` Zhang, Jonathan Zhixiong
2015-08-17 13:05 ` [PATCH V2 1/2] arm64: apei: implement arch_apei_get_mem_attributes() Matt Fleming
2015-08-17 13:05   ` Matt Fleming
2015-08-17 21:09   ` Zhang, Jonathan Zhixiong
2015-08-17 21:09     ` Zhang, Jonathan Zhixiong
  -- strict thread matches above, loose matches on Subject: below --
2015-09-04 13:11 [GIT PULL 0/2] EFI changes for v4.3 (part two) Matt Fleming
2015-09-04 13:11 ` [PATCH 2/2] acpi, apei: Use appropriate pgprot_t to map GHES memory Matt Fleming
2015-09-04 13:11   ` Matt Fleming
2015-08-25 17:27 [PATCH 2/2] acpi, apei: use " Jonathan (Zhixiong) Zhang
2015-08-25 17:27 ` Jonathan (Zhixiong) Zhang
2015-09-04 11:28 ` Matt Fleming
2015-09-04 11:28   ` Matt Fleming
2015-09-04 11:36   ` Ingo Molnar
2015-09-04 11:36     ` Ingo Molnar
2015-08-24 18:25 Jonathan (Zhixiong) Zhang
2015-08-24 18:25 ` Jonathan (Zhixiong) Zhang
2015-08-12 16:17 [GIT PULL 0/2] EFI changes for v4.3 (part two) Matt Fleming
2015-08-12 16:17 ` [PATCH 2/2] acpi, apei: use appropriate pgprot_t to map GHES memory Matt Fleming
2015-08-13  8:19   ` Ingo Molnar
2015-08-13  8:19     ` Ingo Molnar
2015-08-13  9:24     ` Matt Fleming
2015-08-13  9:24       ` Matt Fleming
2015-08-13 11:14       ` Will Deacon
2015-08-13 11:14         ` Will Deacon
2015-08-14 19:09         ` Zhang, Jonathan Zhixiong
2015-08-14 19:09           ` Zhang, Jonathan Zhixiong

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=55DCA61C.8010109@codeaurora.org \
    --to=zjzhang@codeaurora.org \
    --cc=Catalin.Marinas@arm.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=bp@suse.de \
    --cc=hpa@zytor.com \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matt.fleming@intel.com \
    --cc=matt@codeblueprint.co.uk \
    --cc=mingo@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=will.deacon@arm.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.