Re: [PATCH v5 0/2] Incorporate DRAM address in EDAC messages

[Yazen Ghannam]

On Mon, Jun 01, 2026 at 02:05:43PM -0700, Borislav Petkov wrote:
> On Mon, Jun 01, 2026 at 02:41:00PM -0400, Yazen Ghannam wrote:
> > The fake_inject thing looks like it could happen with all EDAC modules.
> > 
> > But it seems unlikely because CONFIG_EDAC_DEBUG needs to be enabled to
> > enable fake_inject. Plus a user would need to use it at the same time as
> > a real DRAM ECC error occurs.
> > 
> > We could add a mutex to the mci struct and hold it during
> > edac_mc_handle_error().
> > 
> > What do you think?
> 
> TBH, I'm wondering if this thing is even used and whether we should simply
> kill it...
> 
> Meh:
> 
> 452a6bf955ee ("edac: Add debufs nodes to allow doing fake error inject")
> 
> it probably is useful.
> 
> How about instead of passing silly ptrs around, we copy the string to a buffer
> local to edac_mc_handle_error() and avoid stupid locking? In a pre-patch
> perhaps...

I think the issue is having concurrent updates to mci->error_desc. EDAC
assumes a single owner for the MCIs. The fake_inject interface basically
acts as a second module/owner.

> 
> This whole thing is itching me to axe it off but meh...
> 

Right, I don't think it's a big deal in practice. IMO, this is a
non-issue.

Thanks,
Yazen