syzbot reported the following ABBA deadlock:

       CPU0                           CPU1
       ----                           ----
  n_vclocks_store()
    lock(&ptp->n_vclocks_mux) [1]
        (physical clock)
                                     pc_clock_adjtime()
                                       lock(&clk->rwsem) [2]
                                        (physical clock)
                                       ...
                                       ptp_clock_freerun()
                                         ptp_vclock_in_use()
                                           lock(&ptp->n_vclocks_mux) [3]
                                              (physical clock)
    ptp_clock_unregister()
      posix_clock_unregister()
        lock(&clk->rwsem) [4]
          (virtual clock)

Functions like clock_adjtime() can only be called with physical clocks.
Therefore, all structures used in this function are physical clocks.

However, when unregistering vclocks in n_vclocks_store(),
ptp->n_vclocks_mux is a physical clock lock, but clk->rwsem of
ptp_clock_unregister() called through device_for_each_child_reverse()
is a virtual clock lock.

Therefore, clk->rwsem used in CPU0 and clk->rwsem used in CPU1 are
different locks, but in lockdep, a false positive occurs because the
possibility of deadlock is determined through lock-class.

Therefore, to prevent such false positive in lockdep, a subclass
annotation must be added to the lock used in the virtual clock structure.

Reported-by: syzbot+7cfb66a237c4a5fb22ad@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=7cfb66a237c4a5fb22ad
Fixes: 73f37068d540 ("ptp: support ptp physical/virtual clocks conversion")
Signed-off-by: Jeongjun Park <aha310510@gmail.com>
---
v3: Annotate lock subclass to prevent false positives of lockdep
- Link to v2: https://lore.kernel.org/all/20250718114958.1473199-1-aha310510@gmail.com/
v2: Add CC Vladimir
- Link to v1: https://lore.kernel.org/all/20250705145031.140571-1-aha310510@gmail.com/
---
 drivers/ptp/ptp_private.h |  5 +++++
 drivers/ptp/ptp_vclock.c  | 16 ++++++++++++++++
 2 files changed, 21 insertions(+)

diff --git a/drivers/ptp/ptp_private.h b/drivers/ptp/ptp_private.h
index a6aad743c282..b352df4cd3f9 100644
--- a/drivers/ptp/ptp_private.h
+++ b/drivers/ptp/ptp_private.h
@@ -24,6 +24,11 @@
 #define PTP_DEFAULT_MAX_VCLOCKS 20
 #define PTP_MAX_CHANNELS 2048
 
+enum {
+	PTP_LOCK_PHYSICAL = 0,
+	PTP_LOCK_VIRTUAL,
+};
+
 struct timestamp_event_queue {
 	struct ptp_extts_event buf[PTP_MAX_TIMESTAMPS];
 	int head;
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);
+}
+#else
+static void ptp_vclock_set_subclass(struct ptp_clock *ptp)
+{
+}
+#endif
+
 static const struct ptp_clock_info ptp_vclock_info = {
 	.owner		= THIS_MODULE,
 	.name		= "ptp virtual clock",
@@ -213,6 +227,8 @@ struct ptp_vclock *ptp_vclock_register(struct ptp_clock *pclock)
 		return NULL;
 	}
 
+	ptp_vclock_set_subclass(vclock->clock);
+
 	timecounter_init(&vclock->tc, &vclock->cc, 0);
 	ptp_schedule_worker(vclock->clock, PTP_VCLOCK_REFRESH_INTERVAL);
 
--

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.

> +}
> +#else
> +static void ptp_vclock_set_subclass(struct ptp_clock *ptp)
> +{
> +}
> +#endif
> +

lockdep_set_subclass() has shim definitions for CONFIG_LOCKDEP=n, you
don't need the #ifdef.

Vladimir Oltean <vladimir.oltean@nxp.com> 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.

On Mon, Jul 21, 2025 at 08:36:17PM +0900, Jeongjun Park wrote:
> 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.

Did you miss the part where I reiterated, in my review comment to your v2,
that after commit 5ab73b010cad ("ptp: fix breakage after ptp_vclock_in_use()
rework"), ptp->n_vclocks_mux is only acquired by physical clocks, not by
virtual clocks?

Also, in general I think it would be useful to include more substantial
pieces of my explanation in your commit message, or link to it in its
entirety. I am worried that the info from it becomes denatured, for
example this piece from your commit message: "Functions like
clock_adjtime() can only be called with physical clocks." I did not say
that, I said that **in order for the clock_adjtime() call to acquire
&ptp->n_vclocks_mux**, then the clock must have been physical.
In general, adjusting a virtual clock is perfectly possible, thus your
restatement is false, and it proves a lack of understanding of the
ptp->n_vclocks_mux locking convention.