Received-SPF: pass (google.com: domain of linux-kernel+bounces-176264-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Fri, 10 May 2024 15:12:36 -0700
From: Dan Williams <dan.j.williams@intel.com>
To: "Fabio M. De Francesco" <fabio.m.de.francesco@linux.intel.com>, "Borislav
 Petkov" <bp@alien8.de>
CC: "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>, Dan Williams
	<dan.j.williams@intel.com>
Subject: Re: [RFC PATCH v2 3/3] ACPI: extlog: Make print_extlog_rcd() log
 unconditionally
Message-ID: <663e9bd4c2525_db82d29451@dwillia2-xfh.jf.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>
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <2881368.Ex9A2HvPv6@fdefranc-mobl3>
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?akcyUlRiZFlCLzlEaVZUdlA1aDVOUFdCdUZLRFQ3cHRYQXhhSVcwSjZGczdI?=
 =?utf-8?B?R3JqbTJkY3Q4dlprWGFPdmEzK2hONmJIbVpweXovRFdPOW5pTUY3SDFOSEhL?=
 =?utf-8?B?TXcxL21IM0hnVkxncmZoTmVINmxqVEN5WjFKUTAxcURpeUJCaEp3Ukd5Y3lq?=
 =?utf-8?B?enVYbzk1WS9OaEJkRVBjUVN5WnhWemtFd1lYZUJySW9FcFhQVU1vYXM2NXRn?=
 =?utf-8?B?Ry9ZSUJ6Y09JQXdNdmlPMm1aMmJmNWFEWmN2eGY1eXZla2pQTHVBZFE1eWhY?=
 =?utf-8?B?b2NMVVBwWTBlZXVpRUFyRk5sSEFKazlGVzhQdXhJMnlpd0RiYzNYV3ZUbXh4?=
 =?utf-8?B?NUJNMVFjSkNMSlJ2YVV5ZEtKTTVHSy9sZ28rRDJuQklXTmk3TmFFUVlmU0Zm?=
 =?utf-8?B?enFFdDFHR0UxRGhMNmY4QlN6aGRRbmp5ek9WYWU5UkRFNWJ2S0FDd0JoVGk2?=
 =?utf-8?B?R09EOTlScUNGS0lkWExRZFhTemF1SGorc0dXM05oSkVrdFQxQkREcTJYeVRq?=
 =?utf-8?B?bnhDSWZPekJCZFdiVTlydVpRT1dRTTBVV2Q0ZG1melIrdjFvUlpIZEpQWXpi?=
 =?utf-8?B?VlRxQWc0SUZKcHVPWnZvL2NDajlLVnVvN0piOGZrYU9rQXI3aHBmaGtiNG5H?=
 =?utf-8?B?dEhpTEZMQWNkNHBoazZxS0pUQzI2cGovMldZN3ZBOGNOY3Z4bjFTcm95M2VW?=
 =?utf-8?B?bjlnNStmblJ4bDBCOFFVK0lzN050WFM0Qm1WZjdzc2JOazZrNWpuSXhLcXp1?=
 =?utf-8?B?UE94d0pVbGEvZkxLdU1KQmNWWDJ2MkswbFIyc1JBWU8rZ1lyeUdOdGtSS01L?=
 =?utf-8?B?bzE4VmduOCtvWnVRQUhtcVhVWThpOEVEKzZUaW45UVEzQUFDL0Y0S0VQM0dh?=
 =?utf-8?B?YWNaOTFHd3laM3ZPZVFZcmIrVTN3T1orTE54MVNTaDUvVEM5QkZHeXU5YXZI?=
 =?utf-8?B?WGN3MXBsWnpZcy9BNGZ3eVkxYW9sMEM4SzJ4bmtRcG5zU01jMzJDSTZBV1lh?=
 =?utf-8?B?VDVXV3BDd08rOGFUWi9icURiK29CczFnNnRxM3E4cWFIcEVCZTA5THVyTVI5?=
 =?utf-8?B?T3VZWjNtbjNFTFhTbzAxSG4vTkxlbU1PVzNYWkwzeTNhR0J2WDU4RTRZOXls?=
 =?utf-8?B?SDd3SWs3UkREemNXMFVRQlhMQVBxSDMzQ2tXZFR3LytWNGlRemRwMk9LUDkz?=
 =?utf-8?B?VjI1a0ZmbTU3eGZBSWNpb242SnY3QWswaitnUkNNeTZUNjAvMXg2cjdwZzRP?=
 =?utf-8?B?VDhFaHVNYUFDSFBDNVdQZHNqZXlLSUdNamJnV0lVZnFMUURRMTl0TWg2cDlu?=
 =?utf-8?B?aEU5dU0rc05UcXluL2ZaT2JiSWk4QzVQenU3UkRpa3h2VjV6TVhRdFpNaWlx?=
 =?utf-8?B?VFBGZ1piK1lGdjNmMS90RlZ2ZENCRlhVTmF4Y1NQT3VqWjZFM2dpOWVGU3pP?=
 =?utf-8?B?Tzd5OGdqbjdOZ0hYaG8vdE5adTBjbWZpY2hkMVZHeEtJdUxYWmhFcUVJbHNn?=
 =?utf-8?B?anp1eGlJb2xRYVNYZ3FJQnJSRUIzd0tsdktaQ1kvc1drSGc1M0F0MDJpYUlX?=
 =?utf-8?B?TXZQQmVDUm16SHdnWE95NldpMkl3dDF0UnZWc0ZpZGNhVjVHOXZJZ3RVT1hE?=
 =?utf-8?B?YndYOW5HazFBYUpPQzRUTjNrM21Va0Vaek92eVhRTUFXU0NnYU5xcTUxd2F4?=
 =?utf-8?B?Rml2ZUtFR2V0a2lpZEJPU1M2dWpaS0xVcEV2Rm1CM2FEQU01YStTY3FUY21T?=
 =?utf-8?B?SFZyZStRYU9HZ1pwaEZ0a1crT1p4TDlNdmpCcXJCRGJ0Rm9jY1U2SXZ4R3RS?=
 =?utf-8?B?RHNBdEZ3MktJd0RGcyt0bW04VmxoNlRxR0hKcTlBVk12UDE1clNlU1NmdUZR?=
 =?utf-8?B?LytYL1FrME83R3JJMVBDYUM2TXNIR3BKY09RZ05mTTRaRnErMXlLRU9wZDNL?=
 =?utf-8?B?bFNGUFc3bGdZS05QRFZGRGxKejAxd2U5bko1WVNYblFPaTFlMzJvTFNmSDkw?=
 =?utf-8?B?dlA1cmQ3M2hJU3VuTmllOEN0NW5aeWJlMWRoS1FqMit6SzJNVlVFTmFERU80?=
 =?utf-8?B?eElPSGg0VWRsN29zV2xUdC9WSEVpNzY3akszVjd5akFacDRNT1k4VDRIcnZD?=
 =?utf-8?B?b3hQeGIxcHJudmM1VW5Va0xNdTdLNmhodnVHZU1FeXNUWXNmK29ualVQWTNX?=
 =?utf-8?B?blE9PQ==?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 11f17389-9c85-4295-8c24-08dc713e4e0c
X-MS-Exchange-CrossTenant-AuthSource: PH8PR11MB8107.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 May 2024 22:12:39.2629
 (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: SYfpQhEMIBQJOwSaQbSrdXkZykfuYt/upfEcLqwjMP5xoHKP7svTRDr1fqCGeonNsFcvmMO9dsEK/4UZcxqJbbX+/vUrUBaVA4Ff0HveJXE=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR11MB5936
X-OriginatorOrg: intel.com

Fabio M. De Francesco wrote:
> On Friday, May 10, 2024 9:25:56 PM GMT+2 Borislav Petkov wrote:
> > On Fri, May 10, 2024 at 09:00:34PM +0200, Fabio M. De Francesco wrote:
> > > I thought that ELOG and GHES should be modeled consistently. ghes_proc()
> > > prints to the console while ghes_do_proc() also uses ftrace.
> > 
> > ghes_proc() calls ghes_do_proc(). I have no clue what you mean here.
> >
> 
> My understanding is that ghes_proc() logs to the console and ghes_do_proc() 
> calls the tracers. 
> 
> Therefore, GHES at the same time always reports the errors via two different 
> means.
> 
> Instead ELOG depends on the check on ras_userspace_consumers() to decide 
> whether to call print_extlog_rcd() to print the logs. And if it print to the 
> kernel logs, it jumps to "out" and skips the tracers.
> 
> Why is it different with respect to how error reporting is made in GHES? 
> 
> I thought that ELOG should be modeled similarly to GHES and so it should print 
> to the kernel logs always unconditionally and then it should also use ftrace 
> (no goto "out" and skip tracers).
> 
> (1) Is my understanding of logging and tracing in ELOG and GHES correct?
> (2) If it is, does it make sense for ELOG to print to the kernel log, 
> unconditionally, and then call the tracers like ghes_proc() + ghes_do_proc() 
> do?

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], 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.

[1]: https://github.com/mchehab/rasdaemon/blob/master/ras-events.c#L992