netdev - Re: [PATCH 7/8] socket: Add SO_TIMESTAMP[NS]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 25 Nov 2018 09:38:41 -0500
From:   Willem de Bruijn <willemdebruijn.kernel@...il.com>
To:     Deepa Dinamani <deepa.kernel@...il.com>
Cc:     David Miller <davem@...emloft.net>,
        LKML <linux-kernel@...r.kernel.org>,
        Network Development <netdev@...r.kernel.org>,
        Al Viro <viro@...iv.linux.org.uk>,
        Arnd Bergmann <arnd@...db.de>,
        y2038 Mailman List <y2038@...ts.linaro.org>,
        jejb@...isc-linux.org, ralf@...ux-mips.org, rth@...ddle.net,
        linux-alpha@...r.kernel.org, linux-mips@...ux-mips.org,
        linux-parisc@...r.kernel.org, linux-rdma@...r.kernel.org,
        sparclinux@...r.kernel.org
Subject: Re: [PATCH 7/8] socket: Add SO_TIMESTAMP[NS]_NEW

> > > > Same for the tcp case above, really, and in the case of the next patch
> > > > for SO_TIMESTAMPING_NEW
> > >
> > > That naming convention, ..._2038, is not the nicest, of course. That
> > > is not the relevant bit in the above comment.
>
> it could be  __sock_recv_timestamp64().
> But, these timestamps should be doing exactly the same thing as the
> old ones and I thought it would be nicer to keep the same code path.
> I can change it to as per above.

Please minimize code changes. It breaks git blame and longer patches
are harder to review.

In this specific case, from a readability point of view, I find new functions
that map one-to-one onto the new interfaces also more readable than
deeper nested branches in place.

> > So we introduce new y2038 safe timestamp options for 32 bit ABIs. We
> > assume that 32 bit applications will switch to new ABIs at some point,
> > but leave the older timestamps as is.
> > I can update the commit text as per above.
>
> We have been avoiding adding timeval64 timestamps to discourage users
> from using these types in the interfaces.
> We want to keep all the uapi time interfaces to use __kernel_*
> interfaces. And, we already provide __kernel_timespec interface for
> such instances.
> But, in this case we do not have an option. So we introduce a type
> specific to sockets.

This structure just holds a timestamp. It does not seem socket specific.
I don't mean to bikeshed the naming point too much, but timeval_ll or
so may be more representative than tying it to a socket.

As for the general naming, xxx64 or xxx2038 are more descriptive than xxx_NEW.