From: "Huang, Ying" <ying.huang@linux.alibaba.com>
To: Borislav Petkov <bp@alien8.de>
Cc: Feng Tang <feng.tang@linux.alibaba.com>,
rafael@kernel.org, Len Brown <lenb@kernel.org>,
James Morse <james.morse@arm.com>,
Tony Luck <tony.luck@intel.com>,
linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
Ira Weiny <ira.weiny@intel.com>,
Dave Jiang <dave.jiang@intel.com>,
Dan Williams <dan.j.williams@intel.com>,
Andi Kleen <ak@linux.intel.com>
Subject: Re: [PATCH] acpi/ghes: Make ghes_panic_timeout adjustable as a parameter
Date: Mon, 30 Dec 2024 19:04:59 +0800 [thread overview]
Message-ID: <87wmfhjusk.fsf@DESKTOP-5N7EMDA> (raw)
In-Reply-To: <20241230101658.GAZ3JzGhRjn7UtoJPt@fat_crate.local> (Borislav Petkov's message of "Mon, 30 Dec 2024 11:16:58 +0100")
Borislav Petkov <bp@alien8.de> writes:
> On Mon, Dec 30, 2024 at 01:54:36PM +0800, Huang, Ying wrote:
>> For example, it may be OK to wait forever for a software error, but it may
>> be better to reboot the system to contain the influence of the hardware
>> error for some hardware errors.
>
> A default panic timeout of 30 seconds for hw errors?! You do realize that 30
> seconds for a machine is an eternity and by that time your hardware error has
> long propagated and corrupted results, right?
>
> So your timeout is not even trying to do what you want.
>
> So unless I'm missing something, this ghes timeout needs to go - if you want
> to "contain the influence" you need to panic *immediately*! And not even that
> would help in some cases - hw has its own protections there so the OS
> panicking is meh. At least on x86, that is.
OK. 30 seconds isn't good enough for hw errors.
Another possible benefit of ghes_panic_timeout is,
rebooting instead of waiting forever can help us to log/report the
hardware errors earlier.
For example, the hardware errors could be logged in some simple
non-volatile storage (such as EFI variables) during panic or kdump, etc.
Then, after reboot, the new kernel could report the hardware errors in
some way.
>> So, we introduced another knob for that.
>
> No, that another knob is piling more of the silly ontop.
---
Best Regards,
Huang, Ying
next prev parent reply other threads:[~2024-12-30 11:05 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-27 9:54 [PATCH] acpi/ghes: Make ghes_panic_timeout adjustable as a parameter Feng Tang
2024-12-27 10:09 ` Borislav Petkov
2024-12-30 5:54 ` Huang, Ying
2024-12-30 10:16 ` Borislav Petkov
2024-12-30 11:04 ` Huang, Ying [this message]
2024-12-30 11:26 ` Borislav Petkov
2024-12-30 11:40 ` Feng Tang
2024-12-30 12:10 ` Borislav Petkov
2024-12-30 13:04 ` Feng Tang
2024-12-30 13:24 ` Borislav Petkov
2024-12-31 6:44 ` Feng Tang
2024-12-31 9:23 ` Borislav Petkov
2024-12-31 10:15 ` Feng Tang
2024-12-31 11:13 ` Borislav Petkov
2024-12-31 12:02 ` Feng Tang
2025-01-02 2:46 ` Huang, Ying
2025-01-02 8:35 ` Borislav Petkov
2025-01-13 12:52 ` [PATCH] APEI: GHES: Have GHES honor the panic= setting Borislav Petkov
2025-01-13 20:08 ` Ira Weiny
2025-01-14 17:29 ` Rafael J. Wysocki
2025-01-09 13:47 ` [PATCH] acpi/ghes: Make ghes_panic_timeout adjustable as a parameter Feng Tang
2025-01-13 12:50 ` Borislav Petkov
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=87wmfhjusk.fsf@DESKTOP-5N7EMDA \
--to=ying.huang@linux.alibaba.com \
--cc=ak@linux.intel.com \
--cc=bp@alien8.de \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=feng.tang@linux.alibaba.com \
--cc=ira.weiny@intel.com \
--cc=james.morse@arm.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=tony.luck@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.