From: Christian Eggers <cegg...@arri.de>
[ Upstream commit 59e611a566e7cd48cf54b6777a11fe3f9c2f9db5 ]
The comparison of optname with SO_TIMESTAMPING_NEW is wrong way around,
so SOCK_TSTAMP_NEW will first be set and than reset again. Additionally
move it out of the test for SOF_TIMESTAMPING_RX_SOFTWARE as this seems
unrelated.
This problem happens on 32 bit platforms were the libc has already
switched to struct timespec64 (from SO_TIMExxx_OLD to SO_TIMExxx_NEW
socket options). ptp4l complains with "missing timestamp on transmitted
peer delay request" because the wrong format is received (and
discarded).
Fixes: 9718475e6908 ("socket: Add SO_TIMESTAMPING_NEW")
Signed-off-by: Christian Eggers <cegg...@arri.de>
Reviewed-by: Willem de Bruijn <willemdebruijn.ker...@gmail.com>
Reviewed-by: Deepa Dinamani <deepa.ker...@gmail.com>
Acked-by: Willem de Bruijn <will...@google.com>
Acked-by: Deepa Dinamani <deepa.ker...@gmail.com>
Signed-off-by: Jakub Kicinski <k...@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
net/core/sock.c | 10 +++-------
1 file changed, 3 insertions(+), 7 deletions(-)
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -928,8 +928,6 @@ set_rcvbuf:
break;
case SO_TIMESTAMPING_NEW:
- sock_set_flag(sk, SOCK_TSTAMP_NEW);
- /* fall through */
case SO_TIMESTAMPING_OLD:
if (val & ~SOF_TIMESTAMPING_MASK) {
ret = -EINVAL;
@@ -958,16 +956,14 @@ set_rcvbuf:
}
sk->sk_tsflags = val;
+ sock_valbool_flag(sk, SOCK_TSTAMP_NEW, optname ==
SO_TIMESTAMPING_NEW);
+
if (val & SOF_TIMESTAMPING_RX_SOFTWARE)
sock_enable_timestamp(sk,
SOCK_TIMESTAMPING_RX_SOFTWARE);
- else {
- if (optname == SO_TIMESTAMPING_NEW)
- sock_reset_flag(sk, SOCK_TSTAMP_NEW);
-
+ else
sock_disable_timestamp(sk,
(1UL <<
SOCK_TIMESTAMPING_RX_SOFTWARE));
- }
break;
case SO_RCVLOWAT:
