EDAC/thunderx: Replace strlcat() with snprintf() and seq_buf

In preparation for removing the strlcat() API[1], replace its uses in the error message construction of the ThunderX OCX and L2C threaded IRQ handlers.

The OCX link and L2C handlers append a single decoded-register string, so the whole message can be produced with one snprintf(). The OCX com handler accumulates a variable number of fragments in a per-lane loop, so use a struct seq_buf, which tracks the current write position and remaining space internally. seq_buf_str() keeps the message NUL-terminated for edac_device_handle_ce().

---
The seq_buf conversion introduces one behavioral difference on overflow. strlcat() copied as much of a fragment as would fit, but seq_buf_puts() is all-or-nothing. A message longer than OCX_MESSAGE_SIZE therefore truncates at a fragment boundary instead of mid-fragment. The message was truncated either way.

I don't have ThunderX hardware, so I tested the patch with:
- arm64 cross-build at W=1 with no warnings. Applies cleanly on v7.2-rc1.
- Module load/unload in an arm64 QEMU guest.
- A userspace harness comparing old and new message construction; outputs matched across ~500k register patterns.

 drivers/edac/thunderx_edac.c | 36 ++++++++++++++++++------------------
 1 file changed, 18 insertions(+), 18 deletions(-)

index 75c04dfc3962..5210ca18473d 100644
@@ -20,6 +20,7 @@
 #include <linux/atomic.h>
 #include <linux/bitfield.h>
 #include <linux/circ_buf.h>
+#include <linux/seq_buf.h>
 
 #include <asm/page.h>
 

@@ -1108,6 +1109,7 @@ static irqreturn_t thunderx_ocx_com_threaded_isr(int irq, void *irq_id)
 	int lane;
 	char *msg;
 	char *other;
+	struct seq_buf sb;
 
 	msg = kmalloc(OCX_MESSAGE_SIZE, GFP_KERNEL);
 	other = kmalloc(OCX_OTHER_SIZE, GFP_KERNEL);

@@ -1121,13 +1123,14 @@ static irqreturn_t thunderx_ocx_com_threaded_isr(int irq, void *irq_id)
 				ARRAY_SIZE(ocx->com_err_ctx));
 		ctx = &ocx->com_err_ctx[tail];
 
-		snprintf(msg, OCX_MESSAGE_SIZE, "%s: OCX_COM_INT: %016llx",
-			ocx->edac_dev->ctl_name, ctx->reg_com_int);
+		seq_buf_init(&sb, msg, OCX_MESSAGE_SIZE);
+		seq_buf_printf(&sb, "%s: OCX_COM_INT: %016llx",
+			       ocx->edac_dev->ctl_name, ctx->reg_com_int);
 
 		decode_register(other, OCX_OTHER_SIZE,
 				ocx_com_errors, ctx->reg_com_int);
 
-		strlcat(msg, other, OCX_MESSAGE_SIZE);
+		seq_buf_puts(&sb, other);
 
 		for (lane = 0; lane < OCX_RX_LANES; lane++)
 			if (ctx->reg_com_int & BIT(lane)) {

@@ -1136,16 +1139,17 @@ static irqreturn_t thunderx_ocx_com_threaded_isr(int irq, void *irq_id)
 					 lane, ctx->reg_lane_int[lane],
 					 lane, ctx->reg_lane_stat11[lane]);
 
-				strlcat(msg, other, OCX_MESSAGE_SIZE);
+				seq_buf_puts(&sb, other);
 
 				decode_register(other, OCX_OTHER_SIZE,
 						ocx_lane_errors,
 						ctx->reg_lane_int[lane]);
-				strlcat(msg, other, OCX_MESSAGE_SIZE);
+				seq_buf_puts(&sb, other);
 			}
 
 		if (ctx->reg_com_int & OCX_COM_INT_CE)
-			edac_device_handle_ce(ocx->edac_dev, 0, 0, msg);
+			edac_device_handle_ce(ocx->edac_dev, 0, 0,
+					      seq_buf_str(&sb));
 
 		ocx->com_ring_tail++;
 	}

@@ -1203,15 +1207,13 @@ static irqreturn_t thunderx_ocx_lnk_threaded_isr(int irq, void *irq_id)
 
 		ctx = &ocx->link_err_ctx[tail];
 
-		snprintf(msg, OCX_MESSAGE_SIZE,
-			 "%s: OCX_COM_LINK_INT[%d]: %016llx",
-			 ocx->edac_dev->ctl_name,
-			 ctx->link, ctx->reg_com_link_int);
-
 		decode_register(other, OCX_OTHER_SIZE,
 				ocx_com_link_errors, ctx->reg_com_link_int);
 
-		strlcat(msg, other, OCX_MESSAGE_SIZE);
+		snprintf(msg, OCX_MESSAGE_SIZE,
+			 "%s: OCX_COM_LINK_INT[%d]: %016llx%s",
+			 ocx->edac_dev->ctl_name,
+			 ctx->link, ctx->reg_com_link_int, other);
 
 		if (ctx->reg_com_link_int & OCX_COM_LINK_INT_UE)
 			edac_device_handle_ue(ocx->edac_dev, 0, 0, msg);

@@ -1882,14 +1884,12 @@ static irqreturn_t thunderx_l2c_threaded_isr(int irq, void *irq_id)
 
 	while (CIRC_CNT(l2c->ring_head, l2c->ring_tail,
 			ARRAY_SIZE(l2c->err_ctx))) {
-		snprintf(msg, L2C_MESSAGE_SIZE,
-			 "%s: %s: %016llx, %s: %016llx",
-			 l2c->edac_dev->ctl_name, reg_int_name, ctx->reg_int,
-			 ctx->reg_ext_name, ctx->reg_ext);
-
 		decode_register(other, L2C_OTHER_SIZE, l2_errors, ctx->reg_int);
 
-		strlcat(msg, other, L2C_MESSAGE_SIZE);
+		snprintf(msg, L2C_MESSAGE_SIZE,
+			 "%s: %s: %016llx, %s: %016llx%s",
+			 l2c->edac_dev->ctl_name, reg_int_name, ctx->reg_int,
+			 ctx->reg_ext_name, ctx->reg_ext, other);
 
 		if (ctx->reg_int & mask_ue)
 			edac_device_handle_ue(l2c->edac_dev, 0, 0, msg);

2.47.3

On Thu, Jul 02, 2026 at 01:46:45AM -0500, Ian Bridges wrote:

Gentle ping. This patch has had no response since it was posted on July 2. The code it converts is unchanged on ras.git edac-for-next as of this week, and the patch still applies cleanly. Happy to resend if that is easier.

Thanks,
Ian

Are you in a hurry with this or is there anything that needs immediate handling?

And I obviously can't apply untested patches.

Also, I see you've CCed the maintainer of that driver so he should probably take a look.

And talking about maintainers, Sashiko points out a bunch of previous issues with this driver:

https://sashiko.dev/#/patchset/akYJUdY1hVABUQH6%40dev

so, Robert, what's the story here, are we still caring for this or can I mark it obsolete and drop it?

Thx.

Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

No, there is no hurry on my end. I'm still new to this process, so if the ping was not appropriate here please let me know.

Thanks,
Ian

Nah, the ping is ok. But soon you'll realize that everyone is overloaded with work.

If you're wondering how to best help out, reviewing and testing patches is very welcome.

Thx.

Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

The driver issues found by Sashiko are valid, the return parameter of snprintf is wrongly used and may cause buffer overflows.

Regarding the mem barrier: On a first glance, it might not be needed here as this runs in the irq handler. That is, there is no concurrent handler and code will not be rescheduled to another cpu. But still, that should be checked in detail.

However, the driver has several issues. I asked Marvell a while ago to take over maintainership, but never got a response. I don't have hardware to test changes. If you mean to mark the driver obsolete, I am good with it. On the other hand, the issues found may not actually trigger and only affect a single system. If we can live with it, we could leave it as is.

Thanks,

-Robert

I am sorting out stuff which needs maintaining from obsolete gunk, which is not used anymore and which doesn't need any maintenance effort or no one cares for it anymore and there's no point to waste precious resources for.

So I'm going to do this but we can always revert it if someone shows interest.

---

Author: Borislav Petkov (AMD) <[email protected]>
Date:   Mon Aug 10 06:40:13 2026 -0700

EDAC/thunderx: Orphan it

Robert doesn't have hardware to test patches anymore and no one else has shown interest in maintaining this driver, so orphan it, for now at least.

index d413dac5c8b3..671515d21bfc 100644
@@ -9308,9 +9308,8 @@ S:	Maintained
 F:	drivers/edac/octeon_edac*
 
 EDAC-CAVIUM THUNDERX
-M:	Robert Richter <[email protected]>
 L:	[email protected]
-S:	Odd Fixes
+S:	Orphan
 F:	drivers/edac/thunderx_edac*
 
 EDAC-CORE

---

Thx.

Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Queued, thanks.

Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette