Re: [PATCH net-next v19 01/13] phylink: Add phylink_mac_interrupt

On 11/10/2026 6:54 am, sashiko-bot@kernel.org wrote:

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] phylink: UAF and TOCTOU in phylink_mac_interrupt due to lockless phydev access
--

commit 667c3fb1a09bf0994b40559aee9027d3f9775442
Author: Birger Koblitz [off-list ref]

phylink: Add phylink_mac_interrupt

Adds the phylink_mac_interrupt() function to phylink, passing link-change
interrupts received by the MAC to phylib.

quoted

diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
index a7d086cdc9b25..a3ca7993eb7e0 100644
--- a/drivers/net/phy/phylink.c
+++ b/drivers/net/phy/phylink.c

[ ... ]

quoted

@@ -1612,6 +1612,26 @@ static bool phylink_link_is_up(struct phylink *pl)
  	return pl->netdev ? netif_carrier_ok(pl->netdev) : pl->old_link_state;
  }
  
+/**
+ * phylink_mac_interrupt() - wrapper for phy_mac_interrupt()
+ * @pl: a pointer to a &struct phylink returned from phylink_create()
+ *
+ * Passes a link-change interrupt received by the MAC to phylib.
+ * This function may be called in interrupt context, and therefore cannot take
+ * a mutex. However, it is safe to assume that the reference to phy does not
+ * disappear during the call, as only an SFP module may be unplugged to make a
+ * PHY disappear. SFP modules however do not support interrupts.
+ */
+void phylink_mac_interrupt(struct phylink *pl)
+{
+	struct phy_device *phy;
+
+	phy = pl->phydev;
+	if (phy)
+		phy_mac_interrupt(phy);

[Severity: High]
The function comment notes that SFP modules do not support interrupts. However,
when an SFP module is physically unplugged, the electrical link drops. Could
this link drop trigger the MAC interrupt being handled here?

The way this code-review is done by whoever handles the AI is absolutely not OK. The same patch was considered to be free of errors in the previous round. Now something is brought up that has been discussed ad nauseam before, including an analysis by Andrew, and found correct.
The minimum I expect is that emails relating to the patches are being looked at and also understood!

Additionally, the AI spits out vast amounts of issues in code-paths for older hardware. Issues that I do not intend to fix, because I simply do not have that hardware to test. Still, reviewing these "issues" takes large amounts of time and even when I complain, the same or similar issues are raised again in the next round.

The "issues" raised by the AI have become more and more absurd and trying to fix them does not really improve code quality, because of possible introduction of new issues and regressions.

I am not going to look further through this AI review as the benefit to effort ratio seems tiny. The code has been tested in-depth. It has been reviewed by several humans. Unless a human steps in and tells me that something really needs to be fixed, at this point it is as good as it gets.

Birger