> Hi,
> 
> On 11/2/26 18:37, Lorenzo Bianconi wrote:
> > stmmac_adjust_time() disables EST, drops est_lock to step the PTP clock,
> > and then reacquires the lock to reprogram EST using a base time computed
> > from the new clock value.
> > 
> > That leaves a window where a concurrent tc_taprio_configure() can program
> > EST enabled with a base time derived from the pre-step clock.  The gate
> > schedule then runs across the PTP step with a stale base time until
> > stmmac_adjust_time() reprograms it.
> > 
> > Keep est_lock held for the whole disable/step/reprogram sequence so no
> > other EST user can program the block while the clock is being stepped.
> > 
> > This does not introduce a new lock ordering: __stmmac_setup_est() already
> > takes ptp_lock through gettimex64() while holding est_lock, and
> > stmmac_adjust_systime() uses readl_poll_timeout_atomic(), so it does not
> > sleep under ptp_lock.
> > 
> > Fixes: 23d96de472f7 ("net: stmmac: re-apply taprio offload in __stmmac_open() and stmmac_resume()")
> > Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@oss.qualcomm.com>
> 
> I couldn't really figure out why the lock was released in the first
> place, LGTM :)

same here :)

> 
> Do you plan on addressing the sashiko pre-existing stuff ? seems to be
> rare conditions but still :( sorry you end up having to deal with these...

yes, I am planning to post a fix for it, I am just awaiting to avoid to post
new patches on the ML before these ones are applied.

Regards,
Lorenzo

> 
> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
> 
> Maxime
>