Re: [PATCH v2 1/3] EDAC/versalnet: Fix teardown ordering in mc_remove()

[Prasanna Kumar T S M]

On 06-04-2026 13:53, Borislav Petkov wrote:
> On Mon, Apr 06, 2026 at 10:56:17AM +0530, Prasanna Kumar T S M wrote:
> > > Sashiko has found things, pls addres them:
> > >
> > > https://sashiko.dev/#/patchset/20260401111836.2342918-1-ptsm%40linux.microsoft.com
> >
> > I asked AI to validate Sashiko's comment.
>
> So I asked *you* to address the Sashiko review. You go and ask another AI to
> validate the review.
>
> Now, if I go and paste the whole conversation to a third AI, the f*ckup is
> complete.
>
> Tell me: is that the goal of this exercise? Let AIs do the thinking
> for us and we can all go shopping?
>
> Or maybe *you* should go review Sashiko's review and say, I agree because
> <proper, comprehensible explanation> or I don't agree because <also proper,
> comprehensible explanation>.
>
> Then *I* go and verify that.
>
> Hmm...

Hi,

Sashiko review says
-------------------
If an MCDI response message arrives after priv->mcdi is freed but before the
RPMSG endpoint is destroyed, could the still-active rpmsg_cb() pass the
dangling priv->mcdi pointer to cdx_mcdi_process_cmd(), leading to a
use-after-free?
-------------------

The review is based on the assumption that priv->mcdi is freed before 
unregister_rpmsg_driver(). But priv->mcdi is valid till the end of the 
function.

The cdx_mcdi_finish() waits for the mcdi->workqueue to finish processing 
and the mcdi->workqueue is destroyed. Any subsequent rpmsg_cb() calls 
cdx_mcdi_process_cmd() which safely without doing anything if mcdi 
(priv->mcdi->mcdi) is NULL. The review can be safely ignored. Other path 
in rpmsg_cb() accesses priv->adec and priv->regs, both of them are valid 
and doesn't cause any use-after-free issue.

The review is a false positive and can be ignored.

Thanks,
Prasanna Kumar