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.
