From: "Pandey, Radhey Shyam" <radheys@amd.com>
To: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>,
linux-edac@vger.kernel.org
Cc: git@amd.com, shubhrajyoti.datta@gmail.com,
Michal Simek <michal.simek@amd.com>,
Borislav Petkov <bp@alien8.de>, Tony Luck <tony.luck@intel.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/9] EDAC/versalnet: Fix device_register() error handling in init_one_mc()
Date: Fri, 31 Jul 2026 16:31:04 +0530 [thread overview]
Message-ID: <e135050d-8965-4e13-a021-ed4674f4856c@amd.com> (raw)
In-Reply-To: <20260724171945.2812749-5-shubhrajyoti.datta@amd.com>
On 7/24/2026 10:49 PM, Shubhrajyoti Datta wrote:
> From: Prasanna Kumar T S M <ptsm@linux.microsoft.com>
>
> When device_register() fails, it must be followed by put_device()
> rather than kfree(), because device_register() calls
> device_initialize() which sets up the device refcount. The matching
> release function versal_edac_release() handles the actual kfree().
>
> To simplify error handling and avoid complex unwinding, split
> device_register() into device_initialize() and device_add().
> Initialize the device early so put_device() can be used in all
> error paths.
>
> Fixes: d5fe2fec6c40 ("EDAC: Add a driver for the AMD Versal NET DDR controller")
> Cc: stable@vger.kernel.org
> Signed-off-by: Prasanna Kumar T S M <ptsm@linux.microsoft.com>
> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
checkpatch reports - warn.
WARNING: Non-standard signature: Co-authored-by:
#20:
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
> Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>
Nit - this is Co-developed-by: candidate as you did changes on top.
> ---
>
> drivers/edac/versalnet_edac.c | 28 ++++++++++++++--------------
> 1 file changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/edac/versalnet_edac.c b/drivers/edac/versalnet_edac.c
> index 03b6e0958f17..3c9eaea5a106 100644
> --- a/drivers/edac/versalnet_edac.c
> +++ b/drivers/edac/versalnet_edac.c
> @@ -785,7 +785,7 @@ static int init_one_mc(struct mc_priv *priv, int i)
> char name[MC_NAME_LEN];
> struct device *dev;
> enum dev_type dt;
> - int rc;
> + int rc = -ENOMEM;
>
> config = priv->adec[CONF + i * ADEC_NUM];
> num_chans = FIELD_GET(MC5_NUM_CHANS_MASK, config);
> @@ -817,23 +817,23 @@ static int init_one_mc(struct mc_priv *priv, int i)
> layers[1].size = num_chans;
> layers[1].is_virt_csrow = false;
>
> - rc = -ENOMEM;
> dev = kzalloc(sizeof(*dev), GFP_KERNEL);
> if (!dev)
> return rc;
>
> - mci = edac_mc_alloc(i, ARRAY_SIZE(layers), layers, sizeof(struct mc_priv));
> - if (!mci) {
> - edac_printk(KERN_ERR, EDAC_MC, "Failed memory allocation for MC%d\n", i);
> - goto err_dev_free;
> - }
> -
> sprintf(name, "versal-net-ddrmc5-edac-%d", i);
>
> dev->init_name = name;
> dev->release = versal_edac_release;
> + device_initialize(dev);
>
There was a comment earlier from sashiko: After splitting
device_register(), the edac_mc_alloc() failure path calls
put_device() with dev->init_name still pointing at a stack
buffer before device_add() copies it. That's unsafe in
principle (dev_name() would follow init_name) and worse with
CONFIG_DEBUG_KOBJECT_RELEASE deferral.
> - rc = device_register(dev);
> + mci = edac_mc_alloc(i, ARRAY_SIZE(layers), layers, sizeof(struct mc_priv));
> + if (!mci) {
> + edac_printk(KERN_ERR, EDAC_MC, "Failed memory allocation for MC%d\n", i);
> + goto err_put_dev;
> + }
> +
> + rc = device_add(dev);
> if (rc)
> goto err_mc_free;
>
> @@ -843,7 +843,7 @@ static int init_one_mc(struct mc_priv *priv, int i)
> rc = edac_mc_add_mc(mci);
> if (rc) {
> edac_printk(KERN_ERR, EDAC_MC, "Failed to register MC%d with EDAC core\n", i);
> - goto err_unreg;
> + goto err_dev_del;
> }
>
> priv->mci[i] = mci;
> @@ -851,12 +851,12 @@ static int init_one_mc(struct mc_priv *priv, int i)
>
> return 0;
>
> -err_unreg:
> - device_unregister(mci->pdev);
> +err_dev_del:
> + device_del(dev);
> err_mc_free:
> edac_mc_free(mci);
> -err_dev_free:
> - kfree(dev);
> +err_put_dev:
> + put_device(dev);
>
> return rc;
> }
next prev parent reply other threads:[~2026-07-31 11:01 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-24 17:19 [PATCH 0/9] EDAC/versalnet: Fix error handling, teardown, and robustness Shubhrajyoti Datta
2026-07-24 17:19 ` [PATCH 1/9] EDAC/versalnet: Add NULL check for mci in handle_error() Shubhrajyoti Datta
2026-07-26 23:52 ` Borislav Petkov
2026-07-27 6:48 ` Pandey, Radhey Shyam
2026-07-28 1:37 ` Borislav Petkov
2026-07-28 18:27 ` Pandey, Radhey Shyam
2026-07-28 21:33 ` Borislav Petkov
2026-07-29 16:40 ` Pandey, Radhey Shyam
2026-07-30 15:03 ` Shubhrajyoti Datta
2026-07-24 17:19 ` [PATCH 2/9] EDAC/versalnet: Add NULL check for mci in remove_one_mc() Shubhrajyoti Datta
2026-07-27 8:11 ` Pandey, Radhey Shyam
2026-07-24 17:19 ` [PATCH 3/9] EDAC/versalnet: Move platform_set_drvdata() to mc_probe() Shubhrajyoti Datta
2026-07-27 8:35 ` Pandey, Radhey Shyam
2026-07-24 17:19 ` [PATCH 4/9] EDAC/versalnet: Fix device_register() error handling in init_one_mc() Shubhrajyoti Datta
2026-07-31 11:01 ` Pandey, Radhey Shyam [this message]
2026-07-24 17:19 ` [PATCH 5/9] EDAC/versalnet: Use dev_set_name() instead of sprintf with init_name Shubhrajyoti Datta
2026-07-31 11:22 ` Pandey, Radhey Shyam
2026-07-24 17:19 ` [PATCH 6/9] EDAC/versalnet: Initialize MCDI before RPMsg registration Shubhrajyoti Datta
2026-07-31 11:41 ` Pandey, Radhey Shyam
2026-07-24 17:19 ` [PATCH 7/9] EDAC/versalnet: Add bounds validation in rpmsg_cb() Shubhrajyoti Datta
2026-07-31 13:56 ` Pandey, Radhey Shyam
2026-07-24 17:19 ` [PATCH 8/9] EDAC/versalnet: Fix use-after-free in remove_one_mc() Shubhrajyoti Datta
2026-07-31 14:06 ` Pandey, Radhey Shyam
2026-07-24 17:19 ` [PATCH 9/9] EDAC/versalnet: Use designated initializer for rpmsg_channel_info Shubhrajyoti Datta
2026-07-31 14:26 ` Pandey, Radhey Shyam
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=e135050d-8965-4e13-a021-ed4674f4856c@amd.com \
--to=radheys@amd.com \
--cc=bp@alien8.de \
--cc=git@amd.com \
--cc=linux-edac@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michal.simek@amd.com \
--cc=shubhrajyoti.datta@amd.com \
--cc=shubhrajyoti.datta@gmail.com \
--cc=tony.luck@intel.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.