Subject: Re: [PATCH net v2] idpf: handle NULL adev in idpf_idc_vdev_mtu_event

From: Simon Horman <[email-masked]>
Date: Wed, 20 May 2026 19:26:31 +0100

On Tue, May 19, 2026 at 09:19:23PM +0100, David CARLIER wrote:
> > This is an AI-generated review of your patch. The human sending this
>   > email has considered the AI review valid, or at least plausible.
> 
>   Thanks for relaying this, Simon.
> 
>   The scenario this patch fixes is sequential, not concurrent:
>   idpf_idc_vport_dev_ctrl(adapter, false) has already returned and
>   vdev_info->adev is NULL by the time ndo_change_mtu reaches
>   idpf_idc_vdev_mtu_event(). The original code dereferenced
>   vdev_info->adev in device_lock() before the NULL check and oopses
>   deterministically; READ_ONCE() + early-return resolves that.
> 
>   A truly concurrent idpf_idc_vport_dev_ctrl(_, false) racing an
>   in-flight MTU event is a separate, pre-existing window: the original
>   code took no reference between reading vdev_info->adev and
>   dereferencing it either, so this patch neither introduces nor widens
>   it. I haven't constructed a concrete interleaving against auxiliary-bus
>   teardown and have no report of it triggering.
> 
>   Happy to post a follow-up bracketing the handler with
>   get_device()/put_device() if you'd prefer, but I'd rather keep this
>   one scoped to the Fixes: target.

Hi David,

Thanks for the clarification.
I agree we can treat concurrency as a separate issue.