From: David Miller <davem@davemloft.net>
To: arnd@arndb.de
Cc: mlichvar@redhat.com, willemb@google.com, bjorn.topel@gmail.com,
gregkh@linuxfoundation.org, francisyyan@gmail.com,
edumazet@google.com, keescook@chromium.org, rami.rosen@intel.com,
andreyknvl@google.com, maloney@google.com,
sowmini.varadhan@oracle.com, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org
Subject: Re: [PATCH] [RFC v2] packet: experimental support for 64-bit timestamps
Date: Tue, 28 Nov 2017 10:05:43 -0500 (EST) [thread overview]
Message-ID: <20171128.100543.834604452984869251.davem@davemloft.net> (raw)
In-Reply-To: <20171128131514.2675733-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Tue, 28 Nov 2017 14:14:05 +0100
> The implementation is fairly straightforward, but I'm less sure about the
> interface. Using SOF_TIMESTAMPING_* flags in PACKET_TIMESTAMP is a bit
> odd already since most of the other flags make no sense here. Adding two
> more flags that only make sense for packet sockets but not the normal
> SO_TIMESTAMPING option on other sockets makes this even more confusing.
We unfortunately never enforced any checking whatsoever of the
PACKET_TIMESTAMP mask the user gives us, we accept anything.
That makes any changes in this area effectively a grenade ready to go
off potentially at any moment.
We can't add new checks without potentially making existing apps stop
working. And at least theoretically if we add new bits it is possible
for an existing app passing those bits in by accident to start
behaving improperly.
I know it sounds like overkill for this, but maybe we can add a new
socket option for the SKIP and 64-bit stuff. That would be %100 safe.
next prev parent reply other threads:[~2017-11-28 15:05 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-27 16:19 [PATCH 1/2] [net-next] packet: clarify timestamp overflow Arnd Bergmann
2017-11-27 16:19 ` [PATCH 2/2] [RFC] packet: experimental support for 64-bit timestamps Arnd Bergmann
2017-11-27 16:59 ` Jiri Pirko
2017-11-27 20:35 ` Willem de Bruijn
2017-11-27 20:51 ` Arnd Bergmann
2017-11-28 7:04 ` Björn Töpel
2017-11-28 8:46 ` Arnd Bergmann
2017-11-28 13:14 ` [PATCH] [RFC v2] " Arnd Bergmann
2017-11-28 14:24 ` Willem de Bruijn
2017-11-28 14:45 ` Arnd Bergmann
2017-11-28 15:05 ` David Miller [this message]
2017-11-28 20:02 ` Arnd Bergmann
2017-11-28 20:08 ` David Miller
2017-11-28 20:31 ` Arnd Bergmann
2017-11-28 20:32 ` [PATCH] [RFC v3] " Arnd Bergmann
2017-11-28 22:28 ` Willem de Bruijn
2017-11-29 12:31 ` Arnd Bergmann
2017-11-29 16:51 ` Willem de Bruijn
2017-11-29 20:06 ` Arnd Bergmann
2017-11-30 1:39 ` Willem de Bruijn
2017-11-30 1:52 ` [PATCH net-next RFC] selftests: test timestamps in psock_tpacket Willem de Bruijn
2017-11-30 1:54 ` [PATCH] [RFC v3] packet: experimental support for 64-bit timestamps Willem de Bruijn
2017-11-29 13:45 ` [PATCH] [RFC v4] " Arnd Bergmann
2017-11-28 14:08 ` [PATCH 2/2] [RFC] " Willem de Bruijn
2017-11-28 14:22 ` Arnd Bergmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171128.100543.834604452984869251.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=andreyknvl@google.com \
--cc=arnd@arndb.de \
--cc=bjorn.topel@gmail.com \
--cc=edumazet@google.com \
--cc=francisyyan@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maloney@google.com \
--cc=mlichvar@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=rami.rosen@intel.com \
--cc=sowmini.varadhan@oracle.com \
--cc=willemb@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).