Re: [PATCH 6/7] PCI/AER: Renumber severity constants

[Lukas Wunner <lukas@wunner.de>]

[cc += Tony Luck, Steven Rostedt, start of thread is here:
https://lore.kernel.org/r/244713dea3786099e9ad4eb10ff9f2f430cd7ad3.1790531238.git.lukas@wunner.de
]

On Sun, Sep 27, 2026 at 06:29:45PM +0000, sashiko-bot@kernel.org wrote:
> PCI/AER: Renumber severity constants
> 
> This commit modifies the AER severity constants to align with the Device Status
> Register bit numbers defined in the PCIe specification. It updates the severity
> strings and the ras_event documentation to reflect the new constant values.
> 
> > +++ b/include/linux/aer.h
> > @@ -11,10 +11,10 @@
> >  #include <linux/errno.h>
> >  #include <linux/types.h>
> >  
> > -#define AER_NONFATAL			0
> > -#define AER_FATAL			1
> > -#define AER_CORRECTABLE			2
> > -#define DPC_FATAL			3
> > +/* Must match bit number in Device Status Register (PCIe r7.1, sec 7.5.3.5) */
> > +#define AER_CORRECTABLE			0
> > +#define AER_NONFATAL			1
> > +#define AER_FATAL			2
> 
> [ ... ]
> 
> > +++ b/include/ras/ras_event.h
> > @@ -302,7 +302,7 @@ TRACE_EVENT(non_standard_event,
> >   *			([domain:]bus:device.function).
> >   * u32 status -		Either the correctable or uncorrectable register
> >   *			indicating what error or errors have been seen
> > - * u8 severity -	error severity 0:NONFATAL 1:FATAL 2:CORRECTED
> > + * u8 severity -	error severity 0:CORRECTED 1:NONFATAL 2:FATAL
> >   */
> 
> [Severity: Critical]
> Does this change unintentionally break the userspace ABI for the aer_event
> tracepoint?
> 
> The tracepoint exports the severity field as a raw u8 integer in the binary
> trace ring buffer. By renumbering the underlying AER constants in
> include/linux/aer.h, the tracepoint now emits different integers for hardware
> error events without an ABI translation layer.
> 
> Userspace tools like rasdaemon that rely on the historical raw integer values
> will now misclassify hardware error severities. For example, a correctable
> error (now 0) would be incorrectly interpreted as non-fatal by older tools
> expecting the previous ABI layout.

Hm, my understanding was that the TP_PROTO() arguments to a TRACE_EVENT()
do not constitute ABI, but rather (only) the string emitted by
TP_printk().

My patch changes the value of a TP_PROTO() argument but not the
TP_printk() output.

However, looking at rasdaemon source code, it's defining constants with
values identical to the kernel:

https://github.com/mchehab/rasdaemon/blob/master/core/ras-events.h#L248

So it looks like this is uAPI without being marked as such and we're stuck
with it. And so apparently patch [6/7] is not applicable and patch [7/7]
needs a fixup. :(

Thanks,

Lukas