From: Dan Williams <dan.j.williams@intel.com>
To: Borislav Petkov <bp@alien8.de>, Dan Williams <dan.j.williams@intel.com>
Cc: "Fabio M. De Francesco" <fabio.m.de.francesco@linux.intel.com>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Len Brown <lenb@kernel.org>, Tony Luck <tony.luck@intel.com>,
<linux-acpi@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<linux-edac@vger.kernel.org>
Subject: Re: [RFC PATCH v2 3/3] ACPI: extlog: Make print_extlog_rcd() log unconditionally
Date: Sun, 12 May 2024 16:45:08 -0700 [thread overview]
Message-ID: <6641548474088_3dce92942b@dwillia2-mobl3.amr.corp.intel.com.notmuch> (raw)
In-Reply-To: <20240511130801.GBZj9tsenZ5SKXgRTm@fat_crate.local>
Borislav Petkov wrote:
> On Fri, May 10, 2024 at 03:12:36PM -0700, Dan Williams wrote:
> > I had asked Fabio to take a look at whether it made sense to continue
> > with the concept of ras_userspace_consumers() especially since it seems
> > limited to the EXTLOG case.
> >
> > In general I am finding that between OS Native and Firmware First error
> > reporting the logging approaches are inconsistent.
> >
> > As far I can see rasdaemon would not even notice is the "daemon_active"
> > debugfs file went away [1],
>
> It tells the kernel that it is consuming the error info from the
> tracepoints.
Yes, my point though was that if it got deleted I doubt anyone would
notice. rasdaemon explicitly does not check the return from
open("daemon_active").
I am also curious about the history here. This "daemon_active" scheme is
an awkward way to detect that something is consuming the tracepoint. It
was added on v4.0, but Steven had added "tracepoint_enabled()" back in
v3.17:
7c65bbc7dcfa tracing: Add trace_<tracepoint>_enabled() function
So even if non-rasdaemon userspace was watching the extlog tracepoints
they would not fire because ras_userspace_consumers() prevents it.
I am finding it difficult to see why ras_userspace_consumers() needs to
continue to be maintained.
> > and it should be the case that the tracepoints always fire whether
> > daemon_active is open or not.
> >
> > So I was expecting this removal to be a conversation starter on the
> > wider topic of error reporting consistency.
>
> Yeah, and then they'll come and say: ew, we're getting error duplicates
> - once logged in dmesg and once through the tracepoints.
That would be odd since there is no ras_userspace_consumers() in the
ACPI GHES path, so it is already the case that you can get duplicate
error information depending on which path triggers the error.
Tracepoints are individually configurable.
> So just like with the other thread, we have to figure out what our
> scheme will be wrt hw error logging, agree on it and then make it
> consistent.
From my perspective I want alignement between "firmware first" and "OS
Native" events and I think any movement away from kernel log messages as
a hardware error mechanism towards tracepoints is a good thing.
Recall that tracepoints can also be configured to emit to the kernel
log, so that might be a way to keep legacy kernel log message parsing
environments happy.
> Do we want to have both? Should it be configurable? Probably...
Would be great to hear from folks that have a reasons for kernel log
message error reporting to continue.
> Anything else...?
Uniformity of error response to "fatal" events, but that is mainly a
PCIe error handling concern not CPU errors.
next prev parent reply other threads:[~2024-05-12 23:45 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-10 11:21 [RFC PATCH v2 0/3] Make ELOG log and trace consistently with GHES Fabio M. De Francesco
2024-05-10 11:21 ` [RFC PATCH v2 1/3] ACPI: extlog: Trace CPER Non-standard Section Body Fabio M. De Francesco
2024-05-10 11:21 ` [RFC PATCH v2 2/3] ACPI: extlog: Trace CPER PCI Express Error Section Fabio M. De Francesco
2024-05-21 19:58 ` Dan Williams
2024-05-10 11:21 ` [RFC PATCH v2 3/3] ACPI: extlog: Make print_extlog_rcd() log unconditionally Fabio M. De Francesco
2024-05-10 12:52 ` Borislav Petkov
2024-05-10 19:00 ` Fabio M. De Francesco
2024-05-10 19:25 ` Borislav Petkov
2024-05-10 20:54 ` Fabio M. De Francesco
2024-05-10 22:12 ` Dan Williams
2024-05-11 13:08 ` Borislav Petkov
2024-05-12 23:45 ` Dan Williams [this message]
2024-05-16 9:57 ` Borislav Petkov
2024-05-16 18:56 ` Dan Williams
2024-05-16 20:03 ` Luck, Tony
2024-05-17 21:43 ` Dan Williams
2024-05-21 18:39 ` 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=6641548474088_3dce92942b@dwillia2-mobl3.amr.corp.intel.com.notmuch \
--to=dan.j.williams@intel.com \
--cc=bp@alien8.de \
--cc=fabio.m.de.francesco@linux.intel.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-edac@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).