[PATCH] cxl/events: Fix event type check for CME counter expiration

[PATCH] cxl/events: Fix event type check for CME counter expiration

[Guixin Liu]

The Memory Event Type field of the General Media and DRAM event
records is an enumeration; 05h designates the advanced programmable
CME counter expiration event. The validity checks for that event
test the field with a bitwise AND against
CXL_GMER_MEM_EVT_TYPE_AP_CME_COUNTER_EXPIRE instead of comparing it
for equality, so benign event types that share a bit with 05h, such
as 01h (Invalid Address), 03h (TE State Violation), 04h (Scrub
Media ECC Error) or 06h (CKID Violation), match too.

A device reporting any of those types with an otherwise valid record
therefore trips WARN_ON_ONCE, once the general media or DRAM
tracepoint is enabled, which is the case for any deployment
collecting CXL events with rasdaemon. The warning panics the kernel
under panic_on_warn=1.

Compare the type field for equality instead.

Found by code inspection during review of a downstream backport of
these two patches. Reproduced in a QEMU CXL topology by injecting a
General Media event with type 01h through the
cxl-inject-general-media-event QMP command, which warns in
cxl_event_trace_record(); with the fix the same injection is traced
without a warning. Events that do violate the spec conditions, type
05h without the threshold event descriptor bit and type 05h with the
bit set but a zero CME count, still warn.

Fixes: cd3b36cfc659 ("cxl/events: Add extra validity checks for corrected memory error count in General Media Event Record")
Fixes: d8145bb8af5c ("cxl/events: Add extra validity checks for CVME count in DRAM Event Record")
Cc: stable@vger.kernel.org
Signed-off-by: Guixin Liu <kanie@linux.alibaba.com>
---
 drivers/cxl/core/mbox.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/cxl/core/mbox.c b/drivers/cxl/core/mbox.c
index 55828a836c01..01341f524a93 100644
--- a/drivers/cxl/core/mbox.c
+++ b/drivers/cxl/core/mbox.c
@@ -942,11 +942,11 @@ void cxl_event_trace_record(struct cxl_memdev *cxlmd,
 
 			if (evt->gen_media.media_hdr.descriptor &
 			    CXL_GMER_EVT_DESC_THRESHOLD_EVENT)
-				WARN_ON_ONCE((evt->gen_media.media_hdr.type &
+				WARN_ON_ONCE((evt->gen_media.media_hdr.type ==
 					      CXL_GMER_MEM_EVT_TYPE_AP_CME_COUNTER_EXPIRE) &&
 					     !get_unaligned_le24(evt->gen_media.cme_count));
 			else
-				WARN_ON_ONCE(evt->gen_media.media_hdr.type &
+				WARN_ON_ONCE(evt->gen_media.media_hdr.type ==
 					     CXL_GMER_MEM_EVT_TYPE_AP_CME_COUNTER_EXPIRE);
 
 			trace_cxl_general_media(cxlmd, type, cxlr, hpa,
@@ -957,11 +957,11 @@ void cxl_event_trace_record(struct cxl_memdev *cxlmd,
 
 			if (evt->dram.media_hdr.descriptor &
 			    CXL_GMER_EVT_DESC_THRESHOLD_EVENT)
-				WARN_ON_ONCE((evt->dram.media_hdr.type &
+				WARN_ON_ONCE((evt->dram.media_hdr.type ==
 					      CXL_DER_MEM_EVT_TYPE_AP_CME_COUNTER_EXPIRE) &&
 					     !get_unaligned_le24(evt->dram.cvme_count));
 			else
-				WARN_ON_ONCE(evt->dram.media_hdr.type &
+				WARN_ON_ONCE(evt->dram.media_hdr.type ==
 					     CXL_DER_MEM_EVT_TYPE_AP_CME_COUNTER_EXPIRE);
 
 			trace_cxl_dram(cxlmd, type, cxlr, hpa, hpa_alias,
-- 
2.43.7

Re: [PATCH] cxl/events: Fix event type check for CME counter expiration

[Dave Jiang]

On 9/21/26 5:09 AM, Guixin Liu wrote:
> The Memory Event Type field of the General Media and DRAM event
> records is an enumeration; 05h designates the advanced programmable
> CME counter expiration event. The validity checks for that event
> test the field with a bitwise AND against
> CXL_GMER_MEM_EVT_TYPE_AP_CME_COUNTER_EXPIRE instead of comparing it
> for equality, so benign event types that share a bit with 05h, such
> as 01h (Invalid Address), 03h (TE State Violation), 04h (Scrub
> Media ECC Error) or 06h (CKID Violation), match too.
> 
> A device reporting any of those types with an otherwise valid record
> therefore trips WARN_ON_ONCE, once the general media or DRAM
> tracepoint is enabled, which is the case for any deployment
> collecting CXL events with rasdaemon. The warning panics the kernel
> under panic_on_warn=1.
> 
> Compare the type field for equality instead.
> 
> Found by code inspection during review of a downstream backport of
> these two patches. Reproduced in a QEMU CXL topology by injecting a
> General Media event with type 01h through the
> cxl-inject-general-media-event QMP command, which warns in
> cxl_event_trace_record(); with the fix the same injection is traced
> without a warning. Events that do violate the spec conditions, type
> 05h without the threshold event descriptor bit and type 05h with the
> bit set but a zero CME count, still warn.

Please consider using the following simplified commit log:

    The Memory Event Type field in the General Media and DRAM event records
    is an enumeration, not a bitmask. The validity checks for the advanced
    programmable CME counter expiration event (05h) test the field with a
    bitwise AND, so types 01h, 03h, 04h and 06h match it as well.

    A device reporting one of those types trips WARN_ON_ONCE once the
    general media or DRAM tracepoint is enabled, which is the case anywhere
    rasdaemon collects CXL events. Under panic_on_warn=1 that kills the
    machine.

    Compare the type field for equality instead. Type 05h records that do
    violate the spec conditions still warn.

Move the explanation on reproducer under '---'.

Otherwise LGTM

DJ

> 
> Fixes: cd3b36cfc659 ("cxl/events: Add extra validity checks for corrected memory error count in General Media Event Record")
> Fixes: d8145bb8af5c ("cxl/events: Add extra validity checks for CVME count in DRAM Event Record")
> Cc: stable@vger.kernel.org
> Signed-off-by: Guixin Liu <kanie@linux.alibaba.com>
> ---
>  drivers/cxl/core/mbox.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/cxl/core/mbox.c b/drivers/cxl/core/mbox.c
> index 55828a836c01..01341f524a93 100644
> --- a/drivers/cxl/core/mbox.c
> +++ b/drivers/cxl/core/mbox.c
> @@ -942,11 +942,11 @@ void cxl_event_trace_record(struct cxl_memdev *cxlmd,
>  
>  			if (evt->gen_media.media_hdr.descriptor &
>  			    CXL_GMER_EVT_DESC_THRESHOLD_EVENT)
> -				WARN_ON_ONCE((evt->gen_media.media_hdr.type &
> +				WARN_ON_ONCE((evt->gen_media.media_hdr.type ==
>  					      CXL_GMER_MEM_EVT_TYPE_AP_CME_COUNTER_EXPIRE) &&
>  					     !get_unaligned_le24(evt->gen_media.cme_count));
>  			else
> -				WARN_ON_ONCE(evt->gen_media.media_hdr.type &
> +				WARN_ON_ONCE(evt->gen_media.media_hdr.type ==
>  					     CXL_GMER_MEM_EVT_TYPE_AP_CME_COUNTER_EXPIRE);
>  
>  			trace_cxl_general_media(cxlmd, type, cxlr, hpa,
> @@ -957,11 +957,11 @@ void cxl_event_trace_record(struct cxl_memdev *cxlmd,
>  
>  			if (evt->dram.media_hdr.descriptor &
>  			    CXL_GMER_EVT_DESC_THRESHOLD_EVENT)
> -				WARN_ON_ONCE((evt->dram.media_hdr.type &
> +				WARN_ON_ONCE((evt->dram.media_hdr.type ==
>  					      CXL_DER_MEM_EVT_TYPE_AP_CME_COUNTER_EXPIRE) &&
>  					     !get_unaligned_le24(evt->dram.cvme_count));
>  			else
> -				WARN_ON_ONCE(evt->dram.media_hdr.type &
> +				WARN_ON_ONCE(evt->dram.media_hdr.type ==
>  					     CXL_DER_MEM_EVT_TYPE_AP_CME_COUNTER_EXPIRE);
>  
>  			trace_cxl_dram(cxlmd, type, cxlr, hpa, hpa_alias,

Re: [PATCH] cxl/events: Fix event type check for CME counter expiration

[Guixin Liu]

在 2026/9/22 00:54, Dave Jiang 写道:
>
> On 9/21/26 5:09 AM, Guixin Liu wrote:
>> The Memory Event Type field of the General Media and DRAM event
>> records is an enumeration; 05h designates the advanced programmable
>> CME counter expiration event. The validity checks for that event
>> test the field with a bitwise AND against
>> CXL_GMER_MEM_EVT_TYPE_AP_CME_COUNTER_EXPIRE instead of comparing it
>> for equality, so benign event types that share a bit with 05h, such
>> as 01h (Invalid Address), 03h (TE State Violation), 04h (Scrub
>> Media ECC Error) or 06h (CKID Violation), match too.
>>
>> A device reporting any of those types with an otherwise valid record
>> therefore trips WARN_ON_ONCE, once the general media or DRAM
>> tracepoint is enabled, which is the case for any deployment
>> collecting CXL events with rasdaemon. The warning panics the kernel
>> under panic_on_warn=1.
>>
>> Compare the type field for equality instead.
>>
>> Found by code inspection during review of a downstream backport of
>> these two patches. Reproduced in a QEMU CXL topology by injecting a
>> General Media event with type 01h through the
>> cxl-inject-general-media-event QMP command, which warns in
>> cxl_event_trace_record(); with the fix the same injection is traced
>> without a warning. Events that do violate the spec conditions, type
>> 05h without the threshold event descriptor bit and type 05h with the
>> bit set but a zero CME count, still warn.
> Please consider using the following simplified commit log:
>
>     The Memory Event Type field in the General Media and DRAM event records
>     is an enumeration, not a bitmask. The validity checks for the advanced
>     programmable CME counter expiration event (05h) test the field with a
>     bitwise AND, so types 01h, 03h, 04h and 06h match it as well.
>
>     A device reporting one of those types trips WARN_ON_ONCE once the
>     general media or DRAM tracepoint is enabled, which is the case anywhere
>     rasdaemon collects CXL events. Under panic_on_warn=1 that kills the
>     machine.
>
>     Compare the type field for equality instead. Type 05h records that do
>     violate the spec conditions still warn.
>
> Move the explanation on reproducer under '---'.
>
OK, changed in v2, thanks.

Best Regards,
Guixin Liu
> Otherwise LGTM
>
> DJ
>
>> Fixes: cd3b36cfc659 ("cxl/events: Add extra validity checks for corrected memory error count in General Media Event Record")
>> Fixes: d8145bb8af5c ("cxl/events: Add extra validity checks for CVME count in DRAM Event Record")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Guixin Liu <kanie@linux.alibaba.com>
>> ---
>>  drivers/cxl/core/mbox.c | 8 ++++----
>>  1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/cxl/core/mbox.c b/drivers/cxl/core/mbox.c
>> index 55828a836c01..01341f524a93 100644
>> --- a/drivers/cxl/core/mbox.c
>> +++ b/drivers/cxl/core/mbox.c
>> @@ -942,11 +942,11 @@ void cxl_event_trace_record(struct cxl_memdev *cxlmd,
>>  
>>  			if (evt->gen_media.media_hdr.descriptor &
>>  			    CXL_GMER_EVT_DESC_THRESHOLD_EVENT)
>> -				WARN_ON_ONCE((evt->gen_media.media_hdr.type &
>> +				WARN_ON_ONCE((evt->gen_media.media_hdr.type ==
>>  					      CXL_GMER_MEM_EVT_TYPE_AP_CME_COUNTER_EXPIRE) &&
>>  					     !get_unaligned_le24(evt->gen_media.cme_count));
>>  			else
>> -				WARN_ON_ONCE(evt->gen_media.media_hdr.type &
>> +				WARN_ON_ONCE(evt->gen_media.media_hdr.type ==
>>  					     CXL_GMER_MEM_EVT_TYPE_AP_CME_COUNTER_EXPIRE);
>>  
>>  			trace_cxl_general_media(cxlmd, type, cxlr, hpa,
>> @@ -957,11 +957,11 @@ void cxl_event_trace_record(struct cxl_memdev *cxlmd,
>>  
>>  			if (evt->dram.media_hdr.descriptor &
>>  			    CXL_GMER_EVT_DESC_THRESHOLD_EVENT)
>> -				WARN_ON_ONCE((evt->dram.media_hdr.type &
>> +				WARN_ON_ONCE((evt->dram.media_hdr.type ==
>>  					      CXL_DER_MEM_EVT_TYPE_AP_CME_COUNTER_EXPIRE) &&
>>  					     !get_unaligned_le24(evt->dram.cvme_count));
>>  			else
>> -				WARN_ON_ONCE(evt->dram.media_hdr.type &
>> +				WARN_ON_ONCE(evt->dram.media_hdr.type ==
>>  					     CXL_DER_MEM_EVT_TYPE_AP_CME_COUNTER_EXPIRE);
>>  
>>  			trace_cxl_dram(cxlmd, type, cxlr, hpa, hpa_alias,

Re: [PATCH] cxl/events: Fix event type check for CME counter expiration

[Alison Schofield]

On Mon, Sep 21, 2026 at 08:09:32PM +0800, Guixin Liu wrote:


Hi Guixin,

Agree w DaveJ's commit log suggestion.

Also, the Subject can be specific, like:
cxl/events: Test CME counter expiry with equality, not bitwise AND

You may want to add something like I've appended below to your agent instructions.
It is intended to better calibrate your agent. Also try giving your agent this
patch (v1 and v2) as a concrete example in the skill. It's a good one because the
original one isn't bad, it is actually thorough and technically valid, but it is
trying to make the commit log serve as the entire bug report, reproduction recipe
and test report. That's exactly the tendency you want this agent to stop doing.

Teach your agent (w example):

For Linux kernel commit messages, be concise and focus on why the change is
needed, not a detailed narration of the investigation.

Structure the commit message as:

1. Background only when needed to understand the problem.
2. Problem: what the current code gets wrong.
3. Impact: the meaningful consequence, especially user-visible impact.
4. Resolution: what the patch changes and why that addresses the problem.
5. Brief "Found by" / "Tested by" information when useful.

Do not include every example, reproduction step, intermediate observation, or
possible consequence just because that information is available. Keep only
details needed to establish the problem and impact.

For small, obvious fixes, aim for roughly 1-3 short paragraphs plus concise
testing information. Explain the semantic error. Do not narrate the code diff.

Subjects should describe the change specifically. Avoid generic "Fix ..."
subjects when a more descriptive imperative subject is available.

-- Alison

Re: [PATCH] cxl/events: Fix event type check for CME counter expiration

[Dave Jiang]

On 9/21/26 10:28 AM, Alison Schofield wrote:
> On Mon, Sep 21, 2026 at 08:09:32PM +0800, Guixin Liu wrote:
> 
> 
> Hi Guixin,
> 
> Agree w DaveJ's commit log suggestion.
> 
> Also, the Subject can be specific, like:
> cxl/events: Test CME counter expiry with equality, not bitwise AND
> 
> You may want to add something like I've appended below to your agent instructions.
> It is intended to better calibrate your agent. Also try giving your agent this
> patch (v1 and v2) as a concrete example in the skill. It's a good one because the
> original one isn't bad, it is actually thorough and technically valid, but it is
> trying to make the commit log serve as the entire bug report, reproduction recipe
> and test report. That's exactly the tendency you want this agent to stop doing.
> 
> Teach your agent (w example):
> 
> For Linux kernel commit messages, be concise and focus on why the change is
> needed, not a detailed narration of the investigation.
> 
> Structure the commit message as:
> 
> 1. Background only when needed to understand the problem.
> 2. Problem: what the current code gets wrong.
> 3. Impact: the meaningful consequence, especially user-visible impact.
> 4. Resolution: what the patch changes and why that addresses the problem.
> 5. Brief "Found by" / "Tested by" information when useful.
> 
> Do not include every example, reproduction step, intermediate observation, or
> possible consequence just because that information is available. Keep only
> details needed to establish the problem and impact.
> 
> For small, obvious fixes, aim for roughly 1-3 short paragraphs plus concise
> testing information. Explain the semantic error. Do not narrate the code diff.
> 
> Subjects should describe the change specifically. Avoid generic "Fix ..."
> subjects when a more descriptive imperative subject is available.
> 
> -- Alison


And if you are uisng an AI agent, please include the following tag:
Assisted-by: LLM

Re: [PATCH] cxl/events: Fix event type check for CME counter expiration

[Guixin Liu]

在 2026/9/22 01:28, Alison Schofield 写道:
> On Mon, Sep 21, 2026 at 08:09:32PM +0800, Guixin Liu wrote:
>
>
> Hi Guixin,
>
> Agree w DaveJ's commit log suggestion.
>
> Also, the Subject can be specific, like:
> cxl/events: Test CME counter expiry with equality, not bitwise AND
>
> You may want to add something like I've appended below to your agent instructions.
> It is intended to better calibrate your agent. Also try giving your agent this
> patch (v1 and v2) as a concrete example in the skill. It's a good one because the
> original one isn't bad, it is actually thorough and technically valid, but it is
> trying to make the commit log serve as the entire bug report, reproduction recipe
> and test report. That's exactly the tendency you want this agent to stop doing.
>
> Teach your agent (w example):
>
> For Linux kernel commit messages, be concise and focus on why the change is
> needed, not a detailed narration of the investigation.
>
> Structure the commit message as:
>
> 1. Background only when needed to understand the problem.
> 2. Problem: what the current code gets wrong.
> 3. Impact: the meaningful consequence, especially user-visible impact.
> 4. Resolution: what the patch changes and why that addresses the problem.
> 5. Brief "Found by" / "Tested by" information when useful.
>
> Do not include every example, reproduction step, intermediate observation, or
> possible consequence just because that information is available. Keep only
> details needed to establish the problem and impact.
>
> For small, obvious fixes, aim for roughly 1-3 short paragraphs plus concise
> testing information. Explain the semantic error. Do not narrate the code diff.
>
> Subjects should describe the change specifically. Avoid generic "Fix ..."
> subjects when a more descriptive imperative subject is available.
Thank you for your patient explanation, I summarized these to a skill, thanks.

Best Regards,
Guixin Liu
> -- Alison