From: Xuanqiang Luo <xuanqiang.luo@linux.dev>
To: Andrew Lunn <andrew@lunn.ch>
Cc: netdev@vger.kernel.org, hkallweit1@gmail.com,
linux@armlinux.org.uk, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, linux-kernel@vger.kernel.org,
Xuanqiang Luo <luoxuanqiang@kylinos.cn>,
stable@vger.kernel.org
Subject: Re: [PATCH net v1] net: phy: fix NULL deref in IRQ handler after unbind
Date: Tue, 25 Aug 2026 11:34:04 +0800 [thread overview]
Message-ID: <749d7a16-df31-4bcc-822b-3153fc69d072@linux.dev> (raw)
In-Reply-To: <e289a01b-d0a5-4296-b8b1-9b5935ee6854@lunn.ch>
Hi Andrew,
在 2026/8/24 20:54, Andrew Lunn 写道:
>> The IRQ is requested at attach time and released by phy_disconnect(),
>> so phy_remove() cannot free it without a later double-free.
> So this sounds wrong.
>
> If you unbind the PHY, you need to also unbind the MAC, since a MAC
> without a PHY is useless. When the MAC unloads, it will call
> phy_remove() so everything unwinds in the correct order.
>
> Andrew
>
> ---
> pw-bot: cr
>
I agree that the MAC should normally be unbound before the PHY.
Also, the paragraph about freeing the IRQ in phy_remove() was
misleading. It was not relevant to the change being proposed,
so I will drop it in v2.
Do you mean that unbinding the PHY first through sysfs is not a
supported operation?
The same sequence was used to reproduce the issue fixed by commit
c2b727df7caa ("net: phy: Avoid NPD upon phy_detach() when driver is
unbound"), which made me think that it should at least not crash:
https://lore.kernel.org/all/20200917034310.2360488-2-f.fainelli@gmail.com/
If this ordering is required, would the right fix be to enforce it
instead?
Thanks,
Xuanqiang
next prev parent reply other threads:[~2026-08-25 3:34 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-24 12:07 [PATCH net v1] net: phy: fix NULL deref in IRQ handler after unbind Xuanqiang Luo
2026-08-24 12:54 ` Andrew Lunn
2026-08-25 3:34 ` Xuanqiang Luo [this message]
2026-08-25 13:03 ` Andrew Lunn
2026-08-26 7:54 ` Xuanqiang Luo
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=749d7a16-df31-4bcc-822b-3153fc69d072@linux.dev \
--to=xuanqiang.luo@linux.dev \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hkallweit1@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=luoxuanqiang@kylinos.cn \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=stable@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 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.