On Fri, Nov 30, 2018 at 5:43 PM Deepa Dinamani [off-list ref] wrote:

On Sun, Nov 25, 2018 at 6:33 AM Willem de Bruijn
[off-list ref] wrote:

quoted

On Sun, Nov 25, 2018 at 12:28 AM Deepa Dinamani [off-list ref] wrote:

quoted

quoted

quoted

quoted

+       if (type == SO_TIMESTAMP_NEW || type == SO_TIMESTAMPNS_NEW)
+               sock_set_flag(sk, SOCK_TSTAMP_NEW);
+       else
+               sock_reset_flag(sk, SOCK_TSTAMP_NEW);
+

if adding a boolean whether the socket uses new or old-style
timestamps, perhaps fail hard if a process tries to set a new-style
option while an old-style is already set and vice versa. Also include
SO_TIMESTAMPING_NEW as it toggles the same option.

I do not think this is a problem.
Consider this example, if there is a user application with updated
socket timestamps is linking into a library that is yet to be updated.

Also consider applications that do not use libraries.

Arnd and I talked about this.
We thought that the new options should behave like the already
existing options. The patch already does this.
Eg: Today if we set SO_TIMESTAMP and then try to switch to
SO_TIMESTAMPNS then there is no fail.

Do you still want a hard fail?

I do think that it is preferable. In general, and in this specific case.

We have had had many bug reports from syzkaller where the fuzzer
manages to trigger unexpected behavior by combining two APIs
that were never intended to be used together.

However inane the combination may be, once an API is published,
we cannot simply add an EINVAL and stop supporting it. So it is safer
to explicitly block unsafe combinations from the start. If there is a
legitimate use it is always possible to loosen that restriction later.

I don't see any sensible use for mixing both the old and the new
interface on the same socket.

That said, just a suggestion.
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038