From: Kuniyuki Iwashima <kuniyu@amazon.com>
To: <willemdebruijn.kernel@gmail.com>
Cc: <davem@davemloft.net>, <edumazet@google.com>, <kuba@kernel.org>,
<kuni1840@gmail.com>, <kuniyu@amazon.com>,
<netdev@vger.kernel.org>, <pabeni@redhat.com>,
<syzkaller@googlegroups.com>, <willemb@google.com>
Subject: RE: [PATCH v1 net] udp: Fix memleaks of sk and zerocopy skbs with TX timestamp.
Date: Mon, 17 Apr 2023 18:54:42 -0700 [thread overview]
Message-ID: <20230418015442.89242-1-kuniyu@amazon.com> (raw)
In-Reply-To: <643df48f6ce39_30336a294a7@willemb.c.googlers.com.notmuch>
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Date: Mon, 17 Apr 2023 21:38:23 -0400
> Kuniyuki Iwashima wrote:
[...]
> > > > So, we need to make sure TX tstamp is not queued if SOCK_DEAD is
> > > > flagged and we purge the queue only after marking SOCK_DEAD ?
> > >
> > > Exactly. Thanks for the sketch.
> > >
> > > Ideally without having to take an extra lock in the common path.
> > > sk_commmon_release calls sk_prot->destroy == udp_destroy_sock,
> > > which already sets SOCK_DEAD.
> > >
> > > Could we move the skb_queue_purge in there? That is also what
> > > calls udp_flush_pending_frames.
> >
> > Yes, that makes sense.
> >
> > I was thinking if we need a memory barrier for SOCK_DEAD to sync
> > with TX, which reads it locklessly. Maybe we should check SOCK_DEAD
> > with sk->sk_error_queue.lock held ?
>
> the flag write needs the lock (which is held). The test_bit in
> sock_flag is atomic.
I was concerning this race:
if (!sock_flag(sk, SOCK_DEAD)) {
sock_flag(sk, SOCK_DEAD)
skb_queue_purge()
skb_queue_tail()
}
and thought we can avoid it by checking SOCK_DEAD under sk_error_queue.lock.
spin_lock_irqsave(sk_error_queue.lock
if (!sock_flag(SOCK_DEAD)) {
sock_flag(SOCK_DEAD) __skb_queue_tail()
}
spin_unlock_irqrestore()
skb_queue_purge()
What do you think ?
>
> > And I forgot to return error from sock_queue_err_skb() to free skb
> > in __skb_complete_tx_timestamp().
> >
> > ---8<---
> > diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> > index 4c0879798eb8..287b834df9c8 100644
> > --- a/net/core/skbuff.c
> > +++ b/net/core/skbuff.c
> > @@ -4979,6 +4979,8 @@ static void skb_set_err_queue(struct sk_buff *skb)
> > */
> > int sock_queue_err_skb(struct sock *sk, struct sk_buff *skb)
> > {
> > + unsigned long flags;
> > +
> > if (atomic_read(&sk->sk_rmem_alloc) + skb->truesize >=
> > (unsigned int)READ_ONCE(sk->sk_rcvbuf))
> > return -ENOMEM;
> > @@ -4992,9 +4994,16 @@ int sock_queue_err_skb(struct sock *sk, struct sk_buff *skb)
> > /* before exiting rcu section, make sure dst is refcounted */
> > skb_dst_force(skb);
> >
> > - skb_queue_tail(&sk->sk_error_queue, skb);
> > - if (!sock_flag(sk, SOCK_DEAD))
> > - sk_error_report(sk);
> > + spin_lock_irqsave(&sk->sk_error_queue.lock, flags);
> > + if (sock_flag(sk, SOCK_DEAD)) {
> > + spin_unlock_irqrestore(&sk->sk_error_queue.lock, flags);
> > + return -EINVAL;
> > + }
> > + __skb_queue_tail(&sk->sk_error_queue, skb);
> > + spin_unlock_irqrestore(&sk->sk_error_queue.lock, flags);
> > +
> > + sk_error_report(sk);
> > +
> > return 0;
> > }
> > EXPORT_SYMBOL(sock_queue_err_skb);
> > diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> > index c605d171eb2d..7060a5cda711 100644
> > --- a/net/ipv4/udp.c
> > +++ b/net/ipv4/udp.c
> > @@ -2674,6 +2674,11 @@ void udp_destroy_sock(struct sock *sk)
> > if (up->encap_enabled)
> > static_branch_dec(&udp_encap_needed_key);
> > }
> > +
> > + /* A zerocopy skb has a refcnt of sk and may be
> > + * put into sk_error_queue with TX timestamp
> > + */
> > + skb_queue_purge(&sk->sk_error_queue);
> > }
> >
> > /*
> > ---8<---
next prev parent reply other threads:[~2023-04-18 1:56 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-17 17:11 [PATCH v1 net] udp: Fix memleaks of sk and zerocopy skbs with TX timestamp Kuniyuki Iwashima
2023-04-17 20:36 ` Willem de Bruijn
2023-04-17 21:26 ` Kuniyuki Iwashima
2023-04-17 21:53 ` Willem de Bruijn
2023-04-17 23:07 ` Kuniyuki Iwashima
2023-04-17 23:28 ` Willem de Bruijn
2023-04-17 23:53 ` Kuniyuki Iwashima
2023-04-18 0:52 ` Willem de Bruijn
2023-04-18 1:24 ` Kuniyuki Iwashima
2023-04-18 1:38 ` Willem de Bruijn
2023-04-18 1:54 ` Kuniyuki Iwashima [this message]
2023-04-18 12:48 ` 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=20230418015442.89242-1-kuniyu@amazon.com \
--to=kuniyu@amazon.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=kuni1840@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=syzkaller@googlegroups.com \
--cc=willemb@google.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 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.