[PATCH net 1/2] socket: fix option SO_TIMESTAMPING_NEW

[PATCH net 1/2] socket: fix option SO_TIMESTAMPING_NEW

[Christian Eggers]

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 <ceggers@arri.de>
---
 net/core/sock.c | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/net/core/sock.c b/net/core/sock.c
index 34a8d12e38d7..3926804702c1 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -1024,16 +1024,15 @@ int sock_setsockopt(struct socket *sock, int level, int optname,
 		}
 
 		sk->sk_tsflags = val;
+		if (optname != SO_TIMESTAMPING_NEW)
+			sock_reset_flag(sk, SOCK_TSTAMP_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:
-- 
Christian Eggers
Embedded software developer

Arnold & Richter Cine Technik GmbH & Co. Betriebs KG
Sitz: Muenchen - Registergericht: Amtsgericht Muenchen - Handelsregisternummer: HRA 57918
Persoenlich haftender Gesellschafter: Arnold & Richter Cine Technik GmbH
Sitz: Muenchen - Registergericht: Amtsgericht Muenchen - Handelsregisternummer: HRB 54477
Geschaeftsfuehrer: Dr. Michael Neuhaeuser; Stephan Schenk; Walter Trauninger; Markus Zeiler

[PATCH net 2/2] socket: don't clear SOCK_TSTAMP_NEW when SO_TIMESTAMPNS is disabled

[Christian Eggers]

SOCK_TSTAMP_NEW (timespec64 instead of timespec) is also used for
hardware time stamps (configured via SO_TIMESTAMPING_NEW).

User space (ptp4l) first configures hardware time stamping via
SO_TIMESTAMPING_NEW which sets SOCK_TSTAMP_NEW. In the next step, ptp4l
disables SO_TIMESTAMPNS(_NEW) (software time stamps), but this must not
switch hardware time stamps back to "32 bit mode".

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: 887feae36aee ("socket: Add SO_TIMESTAMP[NS]_NEW")
Fixes: 783da70e8396 ("net: add sock_enable_timestamps")
Signed-off-by: Christian Eggers <ceggers@arri.de>
---
 net/core/sock.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/net/core/sock.c b/net/core/sock.c
index 3926804702c1..f09053dfb12c 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -757,7 +757,6 @@ static void __sock_set_timestamps(struct sock *sk, bool val, bool new, bool ns)
 	} else {
 		sock_reset_flag(sk, SOCK_RCVTSTAMP);
 		sock_reset_flag(sk, SOCK_RCVTSTAMPNS);
-		sock_reset_flag(sk, SOCK_TSTAMP_NEW);
 	}
 }
 
-- 
Christian Eggers
Embedded software developer

Arnold & Richter Cine Technik GmbH & Co. Betriebs KG
Sitz: Muenchen - Registergericht: Amtsgericht Muenchen - Handelsregisternummer: HRA 57918
Persoenlich haftender Gesellschafter: Arnold & Richter Cine Technik GmbH
Sitz: Muenchen - Registergericht: Amtsgericht Muenchen - Handelsregisternummer: HRB 54477
Geschaeftsfuehrer: Dr. Michael Neuhaeuser; Stephan Schenk; Walter Trauninger; Markus Zeiler

Re: [PATCH net 2/2] socket: don't clear SOCK_TSTAMP_NEW when SO_TIMESTAMPNS is disabled

[Willem de Bruijn]

On Fri, Oct 9, 2020 at 6:32 AM Christian Eggers <ceggers@arri.de> wrote:
>
> SOCK_TSTAMP_NEW (timespec64 instead of timespec) is also used for
> hardware time stamps (configured via SO_TIMESTAMPING_NEW).
>
> User space (ptp4l) first configures hardware time stamping via
> SO_TIMESTAMPING_NEW which sets SOCK_TSTAMP_NEW. In the next step, ptp4l
> disables SO_TIMESTAMPNS(_NEW) (software time stamps), but this must not
> switch hardware time stamps back to "32 bit mode".
>
> 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: 887feae36aee ("socket: Add SO_TIMESTAMP[NS]_NEW")
> Fixes: 783da70e8396 ("net: add sock_enable_timestamps")
> Signed-off-by: Christian Eggers <ceggers@arri.de>

Acked-by: Willem de Bruijn <willemb@google.com>

Yes, we should just select SOCK_TSTAMP_NEW based on which of the two
syscall variants the process uses.

There is no need to reset on timestamp disable: in the common case the
selection is immaterial as timestamping is disabled.

As this commit message shows, with SO_TIMESTAMP(NS) and
SO_TIMESTAMPING that can be independently turned on and off, disabling
one can incorrectly switch modes while the other is still active.

Re: [PATCH net 2/2] socket: don't clear SOCK_TSTAMP_NEW when SO_TIMESTAMPNS is disabled

[Deepa Dinamani]

On Fri, Oct 9, 2020 at 5:35 PM Willem de Bruijn
<willemdebruijn.kernel@gmail.com> wrote:
>
> On Fri, Oct 9, 2020 at 6:32 AM Christian Eggers <ceggers@arri.de> wrote:
> >
> > SOCK_TSTAMP_NEW (timespec64 instead of timespec) is also used for
> > hardware time stamps (configured via SO_TIMESTAMPING_NEW).
> >
> > User space (ptp4l) first configures hardware time stamping via
> > SO_TIMESTAMPING_NEW which sets SOCK_TSTAMP_NEW. In the next step, ptp4l
> > disables SO_TIMESTAMPNS(_NEW) (software time stamps), but this must not
> > switch hardware time stamps back to "32 bit mode".
> >
> > 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: 887feae36aee ("socket: Add SO_TIMESTAMP[NS]_NEW")
> > Fixes: 783da70e8396 ("net: add sock_enable_timestamps")
> > Signed-off-by: Christian Eggers <ceggers@arri.de>
>
> Acked-by: Willem de Bruijn <willemb@google.com>
>
> Yes, we should just select SOCK_TSTAMP_NEW based on which of the two
> syscall variants the process uses.
>
> There is no need to reset on timestamp disable: in the common case the
> selection is immaterial as timestamping is disabled.
>
> As this commit message shows, with SO_TIMESTAMP(NS) and
> SO_TIMESTAMPING that can be independently turned on and off, disabling
> one can incorrectly switch modes while the other is still active.

This will not help the case when a child process that inherits the fd
and then sets SO_TIMESTAMP*_OLD/NEW on it, while the parent uses the
other version.
One of the two processes might still be surprised. But, child and
parent actively using the same socket fd might be expecting trouble
already.

Acked-by: Deepa Dinamani <deepa.kernel@gmail.com>

-Deepa

Re: [PATCH net 1/2] socket: fix option SO_TIMESTAMPING_NEW

[Willem de Bruijn]

On Fri, Oct 9, 2020 at 6:32 AM Christian Eggers <ceggers@arri.de> wrote:
>
> 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 <ceggers@arri.de>
> ---
>  net/core/sock.c | 9 ++++-----
>  1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/net/core/sock.c b/net/core/sock.c
> index 34a8d12e38d7..3926804702c1 100644
> --- a/net/core/sock.c
> +++ b/net/core/sock.c
> @@ -1024,16 +1024,15 @@ int sock_setsockopt(struct socket *sock, int level, int optname,
>                 }
>
>                 sk->sk_tsflags = val;
> +               if (optname != SO_TIMESTAMPING_NEW)
> +                       sock_reset_flag(sk, SOCK_TSTAMP_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);
> -

The idea is to select new vs old behavior depending on which of the
two setsockopts is called.

This suggested fix still sets and clears the flag if calling
SO_TIMESTAMPING_NEW to disable timestamping. Instead, how about

        case SO_TIMESTAMPING_NEW:
-               sock_set_flag(sk, SOCK_TSTAMP_NEW);
                fallthrough;
        case SO_TIMESTAMPING_OLD:
[..]
+               sock_valbool_flag(sk, SOCK_TSTAMP_NEW,
+                                 optname == SO_TIMESTAMPING_NEW);
+
                if (val & SOF_TIMESTAMPING_OPT_ID &&

That is a subtle behavioral change, because it now leaves
SOCK_TSTAMP_NEW set also when timestamping is turned off. But this is
harmless, as in that case the versioning does not matter. A more
pedantic version would be

+               sock_valbool_flag(sk, SOCK_TSTAMP_NEW,
+                                 optname == SO_TIMESTAMPING_NEW &&
+                                 val & SOF_TIMESTAMPING_TX_RECORD_MASK);

Re: [PATCH net 1/2] socket: fix option SO_TIMESTAMPING_NEW

[Deepa Dinamani]

On Fri, Oct 9, 2020 at 3:32 AM Christian Eggers <ceggers@arri.de> wrote:
>
> 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.

The SOCK_TSTAMP_NEW is reset only in the case when
SOF_TIMESTAMPING_RX_SOFTWARE is not set.
Note that we only call sock_enable_timestamp() at that time.

Why would SOCK_TSTAMP_NEW be relevant otherwise?

-Deepa

Re: [PATCH net 1/2] socket: fix option SO_TIMESTAMPING_NEW

[Willem de Bruijn]

On Fri, Oct 9, 2020 at 8:30 PM Deepa Dinamani <deepa.kernel@gmail.com> wrote:
>
> On Fri, Oct 9, 2020 at 3:32 AM Christian Eggers <ceggers@arri.de> wrote:
> >
> > 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.
>
> The SOCK_TSTAMP_NEW is reset only in the case when
> SOF_TIMESTAMPING_RX_SOFTWARE is not set.
> Note that we only call sock_enable_timestamp() at that time.
>
> Why would SOCK_TSTAMP_NEW be relevant otherwise?

Other timestamps can be configured, such as hardware timestamps.

As the follow-on patch shows, there is also the issue of overlap
between SO_TIMESTAMP(NS) and SO_TIMESTAMPING.

Don't select OLD on timestamp disable, which may only disable
some of the ongoing timestamping.

Setting based on the syscall is simpler, too. __sock_set_timestamps
already uses for SO_TIMESTAMP(NS) the valbool approach I
suggest for SO_TIMESTAMPING.

The fallthrough can also be removed. My rough patch missed that.

Re: [PATCH net 1/2] socket: fix option SO_TIMESTAMPING_NEW

[Deepa Dinamani]

On Fri, Oct 9, 2020 at 5:43 PM Willem de Bruijn <willemb@google.com> wrote:
>
> On Fri, Oct 9, 2020 at 8:30 PM Deepa Dinamani <deepa.kernel@gmail.com> wrote:
> >
> > On Fri, Oct 9, 2020 at 3:32 AM Christian Eggers <ceggers@arri.de> wrote:
> > >
> > > 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.
> >
> > The SOCK_TSTAMP_NEW is reset only in the case when
> > SOF_TIMESTAMPING_RX_SOFTWARE is not set.
> > Note that we only call sock_enable_timestamp() at that time.
> >
> > Why would SOCK_TSTAMP_NEW be relevant otherwise?
>
> Other timestamps can be configured, such as hardware timestamps.
>
> As the follow-on patch shows, there is also the issue of overlap
> between SO_TIMESTAMP(NS) and SO_TIMESTAMPING.

I see. Thanks for clarification. I think I had missed that you could
have both software and hardware timestamps enabled at the same time.

> Don't select OLD on timestamp disable, which may only disable
> some of the ongoing timestamping.
>
> Setting based on the syscall is simpler, too. __sock_set_timestamps
> already uses for SO_TIMESTAMP(NS) the valbool approach I
> suggest for SO_TIMESTAMPING.
>
> The fallthrough can also be removed. My rough patch missed that.

Sounds good.

-Deepa