[PATCH v3 3/4] tests/sockopt-timestamp: Don't test old timestamps if unsupported

[Alistair Francis]

On Tue, Mar 17, 2020 at 2:12 AM Dmitry V. Levin <ldv at altlinux.org> wrote:
>
> On Mon, Mar 16, 2020 at 05:02:00PM -0700, Alistair Francis wrote:
> > On Sun, Mar 15, 2020 at 9:35 AM Dmitry V. Levin wrote:
> > > On Fri, Mar 06, 2020 at 06:22:22PM -0800, Alistair Francis wrote:
> > > > On new 32-bit architectures (like RV32) the kernel defines SO_TIMESTAMP
> > > > to SO_TIMESTAMP_NEW (see include/uapi/asm-generic/socket.h:133).
> > > > Although SO_TIMESTAMP_OLD still exists it returns data that doesn't fit
> > > > into the struct timeval as the old timestamp isn't 64-bit (y2038 safe).
> > > >
> > > > To fix this let's skip the test cases if SO_TIMESTAMP is the same as
> > > > SO_TIMESTAMP_NEW. Unfortunately as SO_TIMESTAMP is defined with a one
> > > > line if statement (? :) we can't use preprocess defines and instead need
> > > > to just skipt the tests.
> > >
> > > Sorry, did you say that rv32 kernel can send SO_TIMESTAMP_OLD (and also
> > > SO_TIMESTAMPNS_OLD with SO_TIMESTAMPING_OLD) control messages containing
> > > 32-bit time_t, in contradiction with remaining rv32 types where time_t
> > > is 64-bit?
> >
> > I think so.
> >
> > > This would be so ridiculous for a new architecture that I cannot believe
> > > rv32 kernel behaves this way.
> >
> > Why? There are still lots of syscalls that use a 32-bit time_t.
>
> Really?  Besides those that deal with struct rusage and socket control
> messages?  No, I don't think so.

That is what the kernel does.

You can see here:
https://github.com/torvalds/linux/blob/master/net/compat.c#L224 that
the kernel uses struct __kernel_old_timeval for SO_TIMESTAMP_OLD.

>
> > I sent a new patch series with a new version of this patch as well, so
> > you can see what I am doing there.
>
> According to that series, other syscalls do not use 32-bit time_t on rv32.

Most do not. rusage, SO_TIMESTAMP_OLD and a handful of others do.

>
> I suppose rv32 implements struct rusage using 32-bit time_t for
> consistency with other 32-bit architectures.

Yes, and because it doesn't need a 64-bit time_t here to avoid the
y2038 problem.

>
> Unlike struct rusage, SO_TIMESTAMP*_OLD are deprecated by
> SO_TIMESTAMP*_NEW because SO_TIMESTAMP/SO_TIMESTAMPNS/SO_TIMESTAMPING
> are defined to the corresponding SO_TIMESTAMP*_NEW values on rv32.

Yes. SO_TIMESTAMP* will default to SO_TIMESTAMP*_NEW on RV32, but
SO_TIMESTAMP*_OLD still exists.

There is some more documentation here:
https://github.com/torvalds/linux/blob/master/Documentation/networking/timestamping.txt#L35

>
> So my question is, why rv32 implements
> SO_TIMESTAMP_OLD/SO_TIMESTAMPNS_OLD/SO_TIMESTAMPING_OLD at all,
> and why it implements these control messages using 32-bit time_t?

I didn't write the kernel code, so I don't know for sure. I would
guess it's because every other architecture supports SO_TIMESTAMP*_OLD
so RV32 does as well. It is pretty generic code and not architecture
specific.

As for why SO_TIMESTAMP*_OLD uses __kernel_old_timeval
(https://github.com/torvalds/linux/blob/master/net/compat.c#L224) I
would assume that is to maintain backwards compatibility for other
arches. Again RV32 doesn't do anything special here, it just uses the
generic code.

RV32 is not the only 32-bit architecture, and the y2038 syscalls are
designed to be generic. Most other 32-bit arches will upgrade to use a
64-bit time_t (while RV32 only has 64-bit time_t). In this case the
SO_TIMESTAMP*_OLD calls will work as usual and archs can update to use
the new SO_TIMESTAMP*_NEW calls. RV32 just gets this for free as we
don't have to be backwards compatible.

Alistair

>
>
> --
> ldv