Linux EDAC development
 help / color / mirror / Atom feed
From: Yazen Ghannam <yazen.ghannam@amd.com>
To: Borislav Petkov <bp@alien8.de>
Cc: linux-edac@vger.kernel.org, linux-kernel@vger.kernel.org,
	Avadhut Naik <avanaik92@gmail.com>
Subject: Re: [PATCH v5 0/2] Incorporate DRAM address in EDAC messages
Date: Wed, 10 Jun 2026 17:15:41 -0400	[thread overview]
Message-ID: <20260610211541.GA831811@yaz-khff2.amd.com> (raw)
In-Reply-To: <20260610003516.GBaiixRCclQEMwY_9d@fat_crate.local>

On Tue, Jun 09, 2026 at 05:35:16PM -0700, Borislav Petkov wrote:
> On Thu, Jun 04, 2026 at 11:48:56AM -0400, Yazen Ghannam wrote:
> > 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.
> 
> Ok, something like this. Ugly but it should show the intent. It probably needs
> more auditing whether we have copied all the fields we need down the
> edac_mc_handle_error() path...
> 
> diff --git a/drivers/edac/debugfs.c b/drivers/edac/debugfs.c
> index 8195fc9c9354..034b9b3f9cf5 100644
> --- a/drivers/edac/debugfs.c
> +++ b/drivers/edac/debugfs.c
> @@ -14,28 +14,38 @@ static ssize_t edac_fake_inject_write(struct file *file,
>  	struct mem_ctl_info *mci = to_mci(dev);
>  	static enum hw_event_mc_err_type type;
>  	u16 errcount = mci->fake_inject_count;
> +	struct mem_ctl_info *imci;
> +
> +	imci = kmalloc(sizeof(struct mem_ctl_info), GFP_KERNEL);
> +	if (!imci)
> +		return -ENOMEM;
> +
> +	/* use a local copy and copy the struct */
> +	*imci = *mci;
>  
>  	if (!errcount)
>  		errcount = 1;
>  
> -	type = mci->fake_inject_ue ? HW_EVENT_ERR_UNCORRECTED
> -				   : HW_EVENT_ERR_CORRECTED;
> +	type = imci->fake_inject_ue ? HW_EVENT_ERR_UNCORRECTED
> +				    : HW_EVENT_ERR_CORRECTED;
>  
>  	printk(KERN_DEBUG
>  	       "Generating %d %s fake error%s to %d.%d.%d to test core handling. NOTE: this won't test the driver-specific decoding logic.\n",
>  		errcount,
>  		(type == HW_EVENT_ERR_UNCORRECTED) ? "UE" : "CE",
>  		str_plural(errcount),
> -		mci->fake_inject_layer[0],
> -		mci->fake_inject_layer[1],
> -		mci->fake_inject_layer[2]
> +		imci->fake_inject_layer[0],
> +		imci->fake_inject_layer[1],
> +		imci->fake_inject_layer[2]
>  	       );
> -	edac_mc_handle_error(type, mci, errcount, 0, 0, 0,
> -			     mci->fake_inject_layer[0],
> -			     mci->fake_inject_layer[1],
> -			     mci->fake_inject_layer[2],
> +	edac_mc_handle_error(type, imci, errcount, 0, 0, 0,
> +			     imci->fake_inject_layer[0],
> +			     imci->fake_inject_layer[1],
> +			     imci->fake_inject_layer[2],
>  			     "FAKE ERROR", "for EDAC testing only");
>  
> +	kfree(imci);
> +
>  	return count;
>  }
>  
> 
> 

Right, this fixes the race, and printk/trace would be okay. But the
normal EDAC interface won't get updated. I think that breaks the fake
inject use case.

Ex.
1) Use fake inject to target layer/severity.
2) Check EDAC interface to see layer/severity counters increase.

I don't use the fake inject interface, so I may be mistaken about its
use.

Thanks,
Yazen

  reply	other threads:[~2026-06-10 21:16 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-18 16:07 [PATCH v5 0/2] Incorporate DRAM address in EDAC messages Yazen Ghannam
2026-05-18 16:07 ` [PATCH v5 1/2] RAS/AMD/ATL: Translate UMC normalized address to DRAM address using PRM Yazen Ghannam
2026-05-18 16:07 ` [PATCH v5 2/2] EDAC/amd64: Include DRAM address in output Yazen Ghannam
2026-05-21  0:57 ` [PATCH v5 0/2] Incorporate DRAM address in EDAC messages Borislav Petkov
2026-06-01 18:41   ` Yazen Ghannam
2026-06-01 21:05     ` Borislav Petkov
2026-06-04 15:48       ` Yazen Ghannam
2026-06-10  0:35         ` Borislav Petkov
2026-06-10 21:15           ` Yazen Ghannam [this message]
2026-06-11  1:23             ` Borislav Petkov
2026-06-11 14:11               ` Yazen Ghannam
2026-06-11 16:16                 ` Borislav Petkov
2026-06-11 17:01                   ` Yazen Ghannam
2026-06-12  2:39                     ` Borislav Petkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260610211541.GA831811@yaz-khff2.amd.com \
    --to=yazen.ghannam@amd.com \
    --cc=avanaik92@gmail.com \
    --cc=bp@alien8.de \
    --cc=linux-edac@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox