From: Paolo Abeni <pabeni@redhat.com>
To: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Cc: Matthew Dawson <matthew@mjdsystems.ca>,
Network Development <netdev@vger.kernel.org>,
"Macieira, Thiago" <thiago.macieira@intel.com>
Subject: Re: [PATCH net] datagram: When peeking datagrams with offset < 0 don't skip empty skbs
Date: Tue, 15 Aug 2017 17:40:41 +0200 [thread overview]
Message-ID: <1502811641.3475.7.camel@redhat.com> (raw)
In-Reply-To: <CAF=yD-+ZNPtF1h1OT=_4yuE7=XtireP_OtbyBefHGdwtJ_ontQ@mail.gmail.com>
On Mon, 2017-08-14 at 21:35 -0400, Willem de Bruijn wrote:
> It is not infeasible to fix that and fix up all callers, as Matthew's
> patch does. But perhaps this patch is simpler to reason about. Thoughts?
>
> +static inline bool sk_peek_at_offset(struct sock *sk)
> +{
> + return READ_ONCE(sk->sk_peek_off) >= 0;
> +}
> +
> static inline int sk_peek_offset(struct sock *sk, int flags)
> {
> if (unlikely(flags & MSG_PEEK)) {
> diff --git a/net/core/datagram.c b/net/core/datagram.c
> index ee5647bd91b3..30b53932af73 100644
> --- a/net/core/datagram.c
> +++ b/net/core/datagram.c
> @@ -175,12 +175,14 @@ struct sk_buff *__skb_try_recv_from_queue(struct sock *sk,
> *last = queue->prev;
> skb_queue_walk(queue, skb) {
> if (flags & MSG_PEEK) {
> - if (_off >= skb->len && (skb->len || _off ||
> - skb->peeked)) {
> + if (_off >= skb->len && sk_peek_at_offset(sk) &&
> + (skb->len || _off || skb->peeked)) {
I like the idea a lot, but I think/fear that bad things could happen
since sk_peek_off is read twice at different times: one in
sk_peek_offset() and one in the above chunk.
If the above is not an issue (I am not sure) I'm very fine with this
approach.
For the record, I thought something like the following (uncomplete,
does not even compile):
---
diff --git a/include/linux/socket.h b/include/linux/socket.h
index 8b13db5163cc..5085cf003b88 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -286,6 +286,7 @@ struct ucred {
#define MSG_SENDPAGE_NOTLAST 0x20000 /* sendpage() internal : not the last page */
#define MSG_BATCH 0x40000 /* sendmmsg(): more messages coming */
#define MSG_EOF MSG_FIN
+#define MSG_PEEK_OFF 0x80000
#define MSG_FASTOPEN 0x20000000 /* Send data in TCP SYN */
#define MSG_CMSG_CLOEXEC 0x40000000 /* Set close_on_exec for file
diff --git a/include/net/sock.h b/include/net/sock.h
index 7c0632c7e870..e75e024b55d2 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -504,12 +504,14 @@ enum sk_pacing {
int sk_set_peek_off(struct sock *sk, int val);
-static inline int sk_peek_offset(struct sock *sk, int flags)
+static inline int sk_peek_offset(struct sock *sk, int *flags)
{
- if (unlikely(flags & MSG_PEEK)) {
+ if (unlikely(*flags & MSG_PEEK)) {
s32 off = READ_ONCE(sk->sk_peek_off);
- if (off >= 0)
+ if (off >= 0) {
+ *flags |= MSG_PEEK_OFF;
return off;
+ }
}
return 0;
diff --git a/net/core/datagram.c b/net/core/datagram.c
index ee5647bd91b3..91e1d014d64c 100644
--- a/net/core/datagram.c
+++ b/net/core/datagram.c
@@ -175,8 +175,8 @@ struct sk_buff *__skb_try_recv_from_queue(struct sock *sk,
*last = queue->prev;
skb_queue_walk(queue, skb) {
if (flags & MSG_PEEK) {
- if (_off >= skb->len && (skb->len || _off ||
- skb->peeked)) {
+ if (flags & MSG_PEEK_OFF && _off >= skb->len &&
+ (skb->len || _off || skb->peeked)) {
_off -= skb->len;
continue;
}
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index a7c804f73990..7e1bcd3500f4 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1574,7 +1574,7 @@ int udp_recvmsg(struct sock *sk, struct msghdr *msg, size_t len, int noblock,
return ip_recv_error(sk, msg, len, addr_len);
try_again:
- peeking = off = sk_peek_offset(sk, flags);
+ peeking = off = sk_peek_offset(sk, &flags);
skb = __skb_recv_udp(sk, flags, noblock, &peeked, &off, &err);
if (!skb)
return err;
---
Paolo
next prev parent reply other threads:[~2017-08-15 15:40 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-14 5:52 [PATCH net] datagram: When peeking datagrams with offset < 0 don't skip empty skbs Matthew Dawson
2017-08-14 9:27 ` Paolo Abeni
2017-08-14 14:05 ` Matthew Dawson
2017-08-14 15:03 ` Willem de Bruijn
2017-08-14 15:31 ` Paolo Abeni
2017-08-15 1:35 ` Willem de Bruijn
2017-08-15 15:40 ` Paolo Abeni [this message]
2017-08-15 16:45 ` Willem de Bruijn
2017-08-15 17:00 ` Willem de Bruijn
2017-08-16 9:28 ` Paolo Abeni
2017-08-16 15:18 ` Willem de Bruijn
2017-08-16 20:20 ` Paolo Abeni
2017-08-16 23:27 ` Willem de Bruijn
2017-08-16 23:40 ` Willem de Bruijn
2017-08-16 23:55 ` Thiago Macieira
2017-08-17 0:10 ` Willem de Bruijn
2017-08-17 9:15 ` David Laight
2017-08-17 14:37 ` Willem de Bruijn
2017-08-17 15:47 ` Matthew Dawson
2017-08-17 16:45 ` Willem de Bruijn
2017-08-15 18:17 ` Paolo Abeni
2017-08-14 16:06 ` Thiago Macieira
2017-08-14 16:33 ` Willem de Bruijn
2017-08-14 17:02 ` Thiago Macieira
2017-08-14 18:25 ` Willem de Bruijn
2017-08-14 18:33 ` Thiago Macieira
2017-08-14 18:46 ` Willem de Bruijn
2017-08-14 18:58 ` Thiago Macieira
2017-08-14 19:03 ` Willem de Bruijn
2017-08-14 19:15 ` Thiago Macieira
2017-08-14 19:39 ` Willem de Bruijn
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=1502811641.3475.7.camel@redhat.com \
--to=pabeni@redhat.com \
--cc=matthew@mjdsystems.ca \
--cc=netdev@vger.kernel.org \
--cc=thiago.macieira@intel.com \
--cc=willemdebruijn.kernel@gmail.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).