linux-kernel - Re: [PATCH v2] ptp: remove ptp->n_vclocks check logic in ptp_vclock_in

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250522145037.4715a643@kernel.org>
Date: Thu, 22 May 2025 14:50:37 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Jeongjun Park <aha310510@...il.com>
Cc: richardcochran@...il.com, andrew+netdev@...n.ch, davem@...emloft.net,
 edumazet@...gle.com, pabeni@...hat.com, yangbo.lu@....com,
 netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] ptp: remove ptp->n_vclocks check logic in
 ptp_vclock_in_use()

On Wed, 21 May 2025 01:07:17 +0900 Jeongjun Park wrote:
> The reason why this is appropriate is that any path that uses
> ptp->n_vclocks must unconditionally check if ptp->n_vclocks is greater
> than 0 before unregistering vclocks, and all functions are already
> written this way. And in the function that uses ptp->n_vclocks, we
> already get ptp->n_vclocks_mux before unregistering vclocks.

What about ptp_clock_freerun()? We seem to call it for clock ops
like settime and it does not check n_vclocks.

> Therefore, we need to remove the redundant check for ptp->n_vclocks in
> ptp_vclock_in_use() to prevent recursive locking.

IIUC lockdep is complaining that we are trying to lock the vclock's
n_vclocks_mux, while we already hold that lock for the real clock's
instance. It doesn't understand that the two are in a fixed hierarchy
so the deadlock is not possible.

If my understanding is correct could you please clearly state in the
commit message that this is a false positive? And if so isn't a better
fix to _move_ the !ptp->is_virtual_clock check before the lock in
ptp_vclock_in_use()? that way we preserve current behavior for real
clocks, but vclocks can return early and avoid confusing lockdep?
-- 
pw-bot: cr