Re: [PATCH net v3] ptp: prevent possible ABBA deadlock in ptp_clock_freerun()

[Jeongjun Park]

Vladimir Oltean <vladimir.oltean@xxxxxxx> wrote:
>
> On Sat, Jul 19, 2025 at 09:40:22PM +0900, Jeongjun Park wrote:
> > diff --git a/drivers/ptp/ptp_vclock.c b/drivers/ptp/ptp_vclock.c
> > index 7febfdcbde8b..b16c66c254ae 100644
> > --- a/drivers/ptp/ptp_vclock.c
> > +++ b/drivers/ptp/ptp_vclock.c
> > @@ -154,6 +154,20 @@ static long ptp_vclock_refresh(struct ptp_clock_info *ptp)
> >       return PTP_VCLOCK_REFRESH_INTERVAL;
> >  }
> >
> > +#ifdef CONFIG_LOCKDEP
> > +static void ptp_vclock_set_subclass(struct ptp_clock *ptp)
> > +{
> > +     lockdep_set_subclass(&ptp->n_vclocks_mux, PTP_LOCK_VIRTUAL);
> > +     lockdep_set_subclass(&ptp->clock.rwsem, PTP_LOCK_VIRTUAL);
> > +     lockdep_set_subclass(&ptp->tsevqs_lock, PTP_LOCK_VIRTUAL);
> > +     lockdep_set_subclass(&ptp->pincfg_mux, PTP_LOCK_VIRTUAL);
>
> Every other lock except &ptp->clock.rwsem is unrelated, and I wouldn't
> touch what is unrelated as part of a bug fix. That, plus I believe this
> breaks the data encapsulation of struct posix_clock. At least CC the
> "POSIX CLOCKS and TIMERS" maintainers in v4, so that they're aware of
> your intentions.

Okay, I'll CC the posix_clock maintainers.

However, I think ptp->n_vclocks_mux also needs to be annotating lock
subclass because there may be false positives due to recursive locking
between physical and virtual clocks.