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

[Birger Koblitz <mail@birger-koblitz.de>]

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 <mail@birger-koblitz.de>
> 
> phylink: Add phylink_mac_interrupt
> 
> Adds the phylink_mac_interrupt() function to phylink, passing link-change
> interrupts received by the MAC to phylib.
> 
>> 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
> [ ... ]
>> @@ -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