From: Kuniyuki Iwashima <kuniyu@amazon.com>
To: <mhal@rbox.co>
Cc: <cong.wang@bytedance.com>, <davem@davemloft.net>,
<edumazet@google.com>, <kuba@kernel.org>, <kuni1840@gmail.com>,
<kuniyu@amazon.com>, <netdev@vger.kernel.org>,
<pabeni@redhat.com>
Subject: Re: [PATCH v2 net 01/15] af_unix: Set sk->sk_state under unix_state_lock() for truly disconencted peer.
Date: Sat, 22 Jun 2024 22:19:06 -0700 [thread overview]
Message-ID: <20240623051906.79744-1-kuniyu@amazon.com> (raw)
In-Reply-To: <2d34e8df-cbb0-486a-976b-c5c72554e184@rbox.co>
From: Michal Luczaj <mhal@rbox.co>
Date: Sun, 23 Jun 2024 00:43:27 +0200
> On 6/20/24 23:56, Kuniyuki Iwashima wrote:
> > From: Michal Luczaj <mhal@rbox.co>
> > Date: Thu, 20 Jun 2024 22:35:55 +0200
> >> In fact, should I try to document those not-so-obvious OOB/sockmap
> >> interaction? And speaking of documentation, an astute reader noted that
> >> `man unix` is lying:
> >
> > At least I wouldn't update man until we can say AF_UNIX MSG_OOB handling
> > is stable enough; the behaviour is not compliant with TCP now.
>
> Sure, I get it.
>
> > (...)
> > And we need
> >
> > ---8<---
> > diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
> > index 5e695a9a609c..2875a7ce1887 100644
> > --- a/net/unix/af_unix.c
> > +++ b/net/unix/af_unix.c
> > @@ -2614,9 +2614,20 @@ static struct sk_buff *manage_oob(struct sk_buff *skb, struct sock *sk,
> > struct unix_sock *u = unix_sk(sk);
> >
> > if (!unix_skb_len(skb) && !(flags & MSG_PEEK)) {
> > - skb_unlink(skb, &sk->sk_receive_queue);
> > - consume_skb(skb);
> > - skb = NULL;
> > + struct sk_buff *unlinked_skb = skb;
> > +
> > + spin_lock(&sk->sk_receive_queue.lock);
> > +
> > + __skb_unlink(skb, &sk->sk_receive_queue);
> > +
> > + if (copied)
> > + skb = NULL;
> > + else
> > + skb = skb_peek(&sk->sk_receive_queue);
> > +
> > + spin_unlock(&sk->sk_receive_queue.lock);
> > +
> > + consume_skb(unlinked_skb);
> > } else {
> > struct sk_buff *unlinked_skb = NULL;
> >
> > ---8<---
>
> I gotta ask, is there a reason for unlinking an already consumed
> ('consumed' as in 'unix_skb_len(skb) == 0') skb so late, in manage_oob()?
> IOW, can't it be unlinked immediately once it's consumed in
> unix_stream_recv_urg()? I suppose that would simplify things.
I also thought that before, but we can't do that.
Even after reading OOB data, we need to remember the position
and break recv() at that point. That's why the skb is unlinked
in manage_oob() rather than unix_stream_recv_urg().
next prev parent reply other threads:[~2024-06-23 5:19 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-04 16:52 [PATCH v2 net 00/15] af_unix: Fix lockless access of sk->sk_state and others fields Kuniyuki Iwashima
2024-06-04 16:52 ` [PATCH v2 net 01/15] af_unix: Set sk->sk_state under unix_state_lock() for truly disconencted peer Kuniyuki Iwashima
2024-06-09 11:28 ` Michal Luczaj
2024-06-09 19:53 ` Kuniyuki Iwashima
2024-06-09 21:03 ` Kuniyuki Iwashima
2024-06-10 12:55 ` Michal Luczaj
2024-06-10 17:49 ` Kuniyuki Iwashima
2024-06-16 23:28 ` Michal Luczaj
2024-06-17 18:21 ` Kuniyuki Iwashima
2024-06-19 18:14 ` Michal Luczaj
2024-06-19 19:19 ` Kuniyuki Iwashima
2024-06-20 20:35 ` Michal Luczaj
2024-06-20 21:56 ` Kuniyuki Iwashima
2024-06-22 22:43 ` Michal Luczaj
2024-06-23 5:19 ` Kuniyuki Iwashima [this message]
2024-06-26 10:48 ` Michal Luczaj
2024-06-26 21:56 ` Kuniyuki Iwashima
2024-06-04 16:52 ` [PATCH v2 net 02/15] af_unix: Annodate data-races around sk->sk_state for writers Kuniyuki Iwashima
2024-06-04 16:52 ` [PATCH v2 net 03/15] af_unix: Annotate data-race of sk->sk_state in unix_inq_len() Kuniyuki Iwashima
2024-06-04 16:52 ` [PATCH v2 net 04/15] af_unix: Annotate data-races around sk->sk_state in unix_write_space() and poll() Kuniyuki Iwashima
2024-06-04 16:52 ` [PATCH v2 net 05/15] af_unix: Annotate data-race of sk->sk_state in unix_stream_connect() Kuniyuki Iwashima
2024-06-04 16:52 ` [PATCH v2 net 06/15] af_unix: Annotate data-race of sk->sk_state in unix_accept() Kuniyuki Iwashima
2024-06-04 16:52 ` [PATCH v2 net 07/15] af_unix: Annotate data-races around sk->sk_state in sendmsg() and recvmsg() Kuniyuki Iwashima
2024-06-04 16:52 ` [PATCH v2 net 08/15] af_unix: Annotate data-race of sk->sk_state in unix_stream_read_skb() Kuniyuki Iwashima
2024-06-04 16:52 ` [PATCH v2 net 09/15] af_unix: Annotate data-races around sk->sk_state in UNIX_DIAG Kuniyuki Iwashima
2024-06-04 16:52 ` [PATCH v2 net 10/15] af_unix: Annotate data-races around sk->sk_sndbuf Kuniyuki Iwashima
2024-06-04 16:52 ` [PATCH v2 net 11/15] af_unix: Annotate data-race of net->unx.sysctl_max_dgram_qlen Kuniyuki Iwashima
2024-06-04 16:52 ` [PATCH v2 net 12/15] af_unix: Use unix_recvq_full_lockless() in unix_stream_connect() Kuniyuki Iwashima
2024-06-04 16:52 ` [PATCH v2 net 13/15] af_unix: Use skb_queue_empty_lockless() in unix_release_sock() Kuniyuki Iwashima
2024-06-04 16:52 ` [PATCH v2 net 14/15] af_unix: Use skb_queue_len_lockless() in sk_diag_show_rqlen() Kuniyuki Iwashima
2024-06-04 16:52 ` [PATCH v2 net 15/15] af_unix: Annotate data-race of sk->sk_shutdown in sk_diag_fill() Kuniyuki Iwashima
2024-06-06 11:10 ` [PATCH v2 net 00/15] af_unix: Fix lockless access of sk->sk_state and others fields patchwork-bot+netdevbpf
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=20240623051906.79744-1-kuniyu@amazon.com \
--to=kuniyu@amazon.com \
--cc=cong.wang@bytedance.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=kuni1840@gmail.com \
--cc=mhal@rbox.co \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.