aboutsummaryrefslogtreecommitdiffstats
path: root/net/ipv4/tcp_input.c
diff options
context:
space:
mode:
authorVladimir Oltean <[email protected]>2025-06-13 17:47:49 +0000
committerJakub Kicinski <[email protected]>2025-06-17 23:13:09 +0000
commitaa112cbc5f0ac6f3b44d829005bf34005d9fe9bb (patch)
treea3e0d61c93fd63902093444328f022ee387f2746 /net/ipv4/tcp_input.c
parentptp: fix breakage after ptp_vclock_in_use() rework (diff)
downloadkernel-aa112cbc5f0ac6f3b44d829005bf34005d9fe9bb.tar.gz
kernel-aa112cbc5f0ac6f3b44d829005bf34005d9fe9bb.zip
ptp: allow reading of currently dialed frequency to succeed on free-running clocks
There is a bug in ptp_clock_adjtime() which makes it refuse the operation even if we just want to read the current clock dialed frequency, not modify anything (tx->modes == 0). That should be possible even if the clock is free-running. For context, the kernel UAPI is the same for getting and setting the frequency of a POSIX clock. For example, ptp4l errors out at clock_create() -> clockadj_get_freq() -> clock_adjtime() time, when it should logically only have failed on actual adjustments to the clock, aka if the clock was configured as slave. But in master mode it should work. This was discovered when examining the issue described in the previous commit, where ptp_clock_freerun() returned true despite n_vclocks being zero. Fixes: 73f37068d540 ("ptp: support ptp physical/virtual clocks conversion") Signed-off-by: Vladimir Oltean <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
Diffstat (limited to 'net/ipv4/tcp_input.c')
0 files changed, 0 insertions, 0 deletions