Messages in this thread |  | | Date | Thu, 4 Sep 2025 09:42:33 +0100 | | From | Simon Horman <> | | Subject | Re: [PATCH v2 net 1/2] net: phylink: add lock for serializing concurrent pl->phydev writes with resolver |
| |
On Wed, Sep 03, 2025 at 10:01:45PM +0300, Vladimir Oltean wrote: > On Wed, Sep 03, 2025 at 07:48:58PM +0100, Simon Horman wrote: > > On Wed, Sep 03, 2025 at 06:23:47PM +0300, Vladimir Oltean wrote: > > > @@ -1582,8 +1584,11 @@ static void phylink_resolve(struct work_struct *w) > > > struct phylink_link_state link_state; > > > bool mac_config = false; > > > bool retrigger = false; > > > + struct phy_device *phy; > > > bool cur_link_state; > > > > > > + mutex_lock(&pl->phy_lock); > > > + phy = pl->phydev; > > > > Hi Vladimir, > > > > I guess this is an artifact of the development of this patchset. > > Whatever the case, phy is set but otherwise unused in this function. > > > > This makes CI lightup like a Christmas tree. > > And it's a bit too early in the year for that. > > Thanks for letting me know. It's an artifact of moving patch 1 in front > of 2, and I'll address this for the next revision. > > I downgraded to a slower computer for kernel compilation, and even > though I did compile patch by patch this submission, I had to stop > building with W=1 C=1 for some unrelated bisect and I forgot to turn > them back on. > > I don't have a great solution to this, except I'll try next time to set > up a separate 'git worktree' for noisy stuff like bisection, and try to > keep the net-next environment separate and always with build warnings > and debug options enabled.
Understood. It's a tricky problem.
FWIIW, while it's not perfect - e.g. it doesn't exercise linking - building individual objects does catch problems like this one with low CPU time requirements.
|  |