Received-SPF: pass (google.com: domain of linux-kernel+bounces-177055-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Date: Sun, 12 May 2024 16:45:08 -0700
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
Message-ID: <6641548474088_3dce92942b@dwillia2-mobl3.amr.corp.intel.com.notmuch>
References: <20240510112740.667445-1-fabio.m.de.francesco@linux.intel.com>
 <7009544.jJDZkT8p0M@fdefranc-mobl3>
 <20240510192556.GDZj50xFIWSqK2gzQR@fat_crate.local>
 <2881368.Ex9A2HvPv6@fdefranc-mobl3>
 <663e9bd4c2525_db82d29451@dwillia2-xfh.jf.intel.com.notmuch>
 <20240511130801.GBZj9tsenZ5SKXgRTm@fat_crate.local>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20240511130801.GBZj9tsenZ5SKXgRTm@fat_crate.local>
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?6w3sucP3qMhUIo+LsyJBetnDEltCvMYxHw8m96FoSxDAEwks3aR9ZLnTpDgf?=
 =?us-ascii?Q?F3FINgvdvprJ1ADpB6SGCjrFaHmk3z5J4GH3fDwSu8CCRsIHHKaR1LjXqqOI?=
 =?us-ascii?Q?NL3Oo/GJiEi8FcPhcseLwZrCOxeixn69ZYpfVueY5ewPvtqZfhG1w762S9Md?=
 =?us-ascii?Q?hirkms7KWZejfUYeFBS4U9K6ahTv54Y5NjFjXLreTSuukXS6dPX0Wdu8v0DR?=
 =?us-ascii?Q?Nv1+U/v/V3avWm3NsziOwslGsFk4DEn6nYVUALt82o8Dv6eWCbpYdHkirtAt?=
 =?us-ascii?Q?EVjwdVkG4PulUn2YlYWKU/EI0NfcmmeYr89xfSBtErReJrAiq/pZ5Bd8Xyok?=
 =?us-ascii?Q?uflhT3EwNLESGbfkWmV9e0Uu6NGoUf0MUE/ITlQoqbvbbSHM/HhlZ5bavM0F?=
 =?us-ascii?Q?uRXK2tYcAuUkGhNTmVegxLPQN9xddiNUC+vupeaONGAprGI6Im/Z43tLxg1e?=
 =?us-ascii?Q?4ix0zcQGSqmVAe04U1cP0qGPEB5JoSkKlA+7Y3Lz7L3lTQoH6f0haXPv8jOs?=
 =?us-ascii?Q?QHxaPzafYoiDpA/Av2dJH4MSmG0RosGWWtVrcsblffXnyUnroj2E1NSGwZUg?=
 =?us-ascii?Q?34n24hbJ8T69nKtYEz7vOgYUNBqM5k/vb1Gurn2sUe4+Q1FeQ0EDIy9XAr/L?=
 =?us-ascii?Q?Iie2fBOe70AwDZ63Hi6E/yUlJYT7l5WUQN5jjz78um/uwL/AY/bK02YWo3uT?=
 =?us-ascii?Q?802SOivOfzQBq4aS+BFfg/Xlzhh3UPi3ZmN+L4w8mHD51a44mYHzPs1peOaA?=
 =?us-ascii?Q?nwveAMC975dpPyApJr5k4nTBy+1Sfs1e2UV8HM1qAPMJmYidjBylYKbSXmXF?=
 =?us-ascii?Q?tBbLjWhdoUqObRB2hAVFyCO7lZUuONuZCbcwQjsvZK2uacSfNx765dHzBDB0?=
 =?us-ascii?Q?n3MpbGuU5g5DcicXAYCJ3Ou2dEw18vLULfD47BMkLtAxkykgcXFT0/u1YFn3?=
 =?us-ascii?Q?JCTVoyOpbZQ2/8HpiEN65u5D5zvMthTWC63f+AF57ohCdQFA2Wt+4ehGc0Ue?=
 =?us-ascii?Q?k9tn/3tiNlp+cz+mfgZC9K9R7r2lpDBEH9l50QxZng6hqRTdfn+l8HNlww9J?=
 =?us-ascii?Q?WB64vX0g62lUKa3GtoGyA1WAbh8IJA5CqFYqIb5EdmvP9q8DvtGULIUhml75?=
 =?us-ascii?Q?UFfICaEzEOqOXZyveWq4uCgmuMUq+Q1grH89S/mWy0lm1MAYcMSxnEXBZzuj?=
 =?us-ascii?Q?1j0aYkutWYWodrOAU5ecFXCLGwT6seXRlPH/JCIA6uc7QuJLUHJFTtojCRMP?=
 =?us-ascii?Q?PfKC6VEu5hgvHwjnIsfcoaOZQAfyoDWNCJalguQqo6Hq8QiMeIJvZy1h2W3s?=
 =?us-ascii?Q?Uu31tD0kHOz2zg1BuxtBQe45lcibLs6PeAKTeR3/JEQGOYSBocjTSaPDxiAL?=
 =?us-ascii?Q?nFDk9Ka1BYW9eVUnVzlCLgxis4kFVXgmGy2UEWfuhPsMmg4tMO9PJTgl0N/0?=
 =?us-ascii?Q?Bv9zOZPS0FrjQDgcKloYCdb2CtOT+fxIDAkuEVCYBzA56TSVh4cfSW/N9s+P?=
 =?us-ascii?Q?DfXdBoCtXrPieUd17+yXGYrrRqgGkhdELojzTiWkiY8s3BdfVUXWohBcYToS?=
 =?us-ascii?Q?75sILR2Lob/gV1mV/f1t/D4TyjGAZmINo3XODBDGMVwyPDIfXEDMA/LemdKs?=
 =?us-ascii?Q?oQ=3D=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 9632dca6-b2a1-43a1-f735-08dc72dd8f8d
X-MS-Exchange-CrossTenant-AuthSource: PH8PR11MB8107.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 May 2024 23:45:10.2716
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: MPITneHxuYlwXpfN3oTjeV2bstsZ283/Waaj6Nzokb3e17rqLmxXWsZcXZIh6N6y8YsXCj+unuqVotZymUcKaJmoknl8ovU1yf4beM5sbIs=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR11MB5105
X-OriginatorOrg: intel.com

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.