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: <CAO9qdTHuDb9Uqu3zqjnV6PdX9ExWv24Q9_JfQ8FbKigipDrN+Q@mail.gmail.com>
Date: Mon, 26 May 2025 20:00:53 +0900
From: Jeongjun Park <aha310510@...il.com>
To: Jakub Kicinski <kuba@...nel.org>
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()

Jakub Kicinski <kuba@...nel.org> wrote:
>
> 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.

ptp_clock_freerun() calls ptp_vclock_in_use() to 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

Your right! This deadlock report seems to be a false positive. It seems
appropriate to add a description of this false positive to the commit
message.

However, it is not appropriate to move the code that checks
ptp->is_virtual_clock. If you need to check n_vclocks when checking
whether ptp virtual clock is in use, it means that caller function has
already performed work related to n_vclocks, and in this case, it is
appropriate to perform n_vclocks check and n_vclocks_mux lock in caller
function.

Therefore, considering the overall structure, it is more appropriate to
remove unnecessary locks and n_vclocks checks in ptp_vclock_in_use().