From: Simon Horman <horms@kernel.org>
To: Deep Shah <deepshah146@gmail.com>
Cc: netdev@vger.kernel.org,
Richard Cochran <richardcochran@gmail.com>,
"David S . Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Eric Dumazet <edumazet@google.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
Shuah Khan <shuah@kernel.org>,
Vadim Fedorenko <vadim.fedorenko@linux.dev>
Subject: Re: [PATCH v2 net 2/2] selftests: ptp: add a regression test for the frequency adjustment overflow
Date: Mon, 27 Jul 2026 12:28:23 +0100 [thread overview]
Message-ID: <20260727112823.GN418547@horms.kernel.org> (raw)
In-Reply-To: <20260721014256.1876-3-deepshah146@gmail.com>
On Tue, Jul 21, 2026 at 01:42:56AM +0000, Deep Shah wrote:
> testptp's -f option stores the requested adjustment as an int ppb and
> converts it to scaled ppm, so it cannot express the 64-bit scaled-ppm
> values needed to overflow scaled_ppm_to_ppb() and bypass the max_adj
> check enforced by ptp_clock_adjtime().
>
> Add a small test that crafts struct timex.freq directly and verifies that
> an overflowing frequency adjustment is rejected with -ERANGE. The test
> skips when no frequency-adjustable PTP device is available.
>
> Signed-off-by: Deep Shah <deepshah146@gmail.com>
...
> diff --git a/tools/testing/selftests/ptp/ptp_freq_overflow.c b/tools/testing/selftests/ptp/ptp_freq_overflow.c
...
> + /*
> + * (1 + 147573952589676412) * 125 == 2^64 + 9, which overflows s64 in
> + * scaled_ppm_to_ppb() and wraps the result to a ppb of 0. A kernel
> + * that does not detect the overflow lets this absurd frequency past
> + * the max_adj check; a fixed kernel rejects it with -ERANGE.
> + */
> + tx.modes = ADJ_FREQUENCY;
> +#if __SIZEOF_LONG__ >= 8
> + tx.freq = 147573952589676412L;
> +#endif
Thanks for the update here.
But unfortunately sashiko.dev still flags a problem.
"Will this preprocessor condition cause a false test failure on 32-bit
architectures configured with 64-bit time types (such as x32 or y2038
compliant systems)?
"On those architectures, the runtime check earlier in main() passes because
sizeof(tx.freq) is 8. However, __SIZEOF_LONG__ evaluates to 4, which causes
the preprocessor to skip the assignment of tx.freq.
"This leaves tx.freq as 0, allowing clock_adjtime() to successfully apply
a zero adjustment instead of rejecting the call with -ERANGE, which triggers
a test failure.
I wonder if dropping the #if/#endif would address that concern.
prev parent reply other threads:[~2026-07-27 11:28 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-21 1:42 [PATCH v2 net 0/2] ptp: fix scaled_ppm_to_ppb() overflow bypassing the max_adj check Deep Shah
2026-07-21 1:42 ` [PATCH v2 net 1/2] ptp: reject frequency adjustments that overflow scaled_ppm_to_ppb() Deep Shah
2026-07-27 20:22 ` Jakub Kicinski
2026-07-21 1:42 ` [PATCH v2 net 2/2] selftests: ptp: add a regression test for the frequency adjustment overflow Deep Shah
2026-07-27 11:28 ` Simon Horman [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260727112823.GN418547@horms.kernel.org \
--to=horms@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=deepshah146@gmail.com \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=richardcochran@gmail.com \
--cc=shuah@kernel.org \
--cc=vadim.fedorenko@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.