bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hawkins Jiawei <yin31149@gmail.com>
To: kafai@fb.com
Cc: 18801353760@163.com, andrii@kernel.org, ast@kernel.org,
	borisp@nvidia.com, bpf@vger.kernel.org, daniel@iogearbox.net,
	davem@davemloft.net, edumazet@google.com,
	guwen@linux.alibaba.com, jakub@cloudflare.com,
	john.fastabend@gmail.com, kgraul@linux.ibm.com,
	kpsingh@kernel.org, kuba@kernel.org,
	linux-kernel-mentees@lists.linuxfoundation.org,
	linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
	pabeni@redhat.com, paskripkin@gmail.com,
	skhan@linuxfoundation.org, songliubraving@fb.com,
	syzbot+5f26f85569bd179c18ce@syzkaller.appspotmail.com,
	syzkaller-bugs@googlegroups.com, yhs@fb.com, yin31149@gmail.com
Subject: Re: [PATCH v4] net: fix refcount bug in sk_psock_get (2)
Date: Thu,  4 Aug 2022 11:05:15 +0800	[thread overview]
Message-ID: <20220804030514.7118-1-yin31149@gmail.com> (raw)
In-Reply-To: <20220803153706.oo47lv3kvkpb7yem@kafai-mbp.dhcp.thefacebook.com>

On Wed, 3 Aug 2022 at 23:37, Martin KaFai Lau <kafai@fb.com> wrote:
> > > + * SK_USER_DATA_BPF    - Managed by BPF
> >
> > I'd use this opportunity to add more info here, BPF is too general.
> > Maybe "Pointer is used by a BPF reuseport array"? Martin, WDYT?
> SGTM.  Thanks.
OK. It seems that this flag is introduced from
c9a368f1c0fb ("bpf: net: Avoid incorrect bpf_sk_reuseport_detach call").
I will search for more detailed description in this commit.

> >
> > > +/**
> > > + * rcu_dereference_sk_user_data_psock - return psock if sk_user_data
> > > + * points to the psock type(SK_USER_DATA_PSOCK flag is set), otherwise
> > > + * return NULL
> > > + *
> > > + * @sk: socket
> > > + */
> > > +static inline
> > > +struct sk_psock *rcu_dereference_sk_user_data_psock(const struct sock *sk)
> >
> > nit: the return type more commonly goes on the same line as "static
> > inline"
Ok. I will correct it.

> >
> > > +{
> > > +     uintptr_t __tmp = (uintptr_t)rcu_dereference(__sk_user_data((sk)));
> > > +
> > > +     if (__tmp & SK_USER_DATA_PSOCK)
> > > +             return (struct sk_psock *)(__tmp & SK_USER_DATA_PTRMASK);
> > > +
> > > +     return NULL;
> > > +}
> >
> > As a follow up we can probably generalize this into
> >  __rcu_dereference_sk_user_data_cond(sk, bit)
> >
> > and make the psock just call that:
> >
> > static inline struct sk_psock *
> > rcu_dereference_sk_user_data_psock(const struct sock *sk)
> > {
> >         return __rcu_dereference_sk_user_data_cond(sk, SK_USER_DATA_PSOCK);
> > }
Yes. I will refactor it in this way.

> >
> > diff --git a/kernel/bpf/reuseport_array.c b/kernel/bpf/reuseport_array.c
> > index e2618fb5870e..ad5c447a690c 100644
> > --- a/kernel/bpf/reuseport_array.c
> > +++ b/kernel/bpf/reuseport_array.c
> > @@ -21,14 +21,11 @@ static struct reuseport_array *reuseport_array(struct bpf_map *map)
> >  /* The caller must hold the reuseport_lock */
> >  void bpf_sk_reuseport_detach(struct sock *sk)
> >  {
> > -       uintptr_t sk_user_data;
> > +       struct sock __rcu **socks;
> >
> >         write_lock_bh(&sk->sk_callback_lock);
> > -       sk_user_data = (uintptr_t)sk->sk_user_data;
> > -       if (sk_user_data & SK_USER_DATA_BPF) {
> > -               struct sock __rcu **socks;
> > -
> > -               socks = (void *)(sk_user_data & SK_USER_DATA_PTRMASK);
> > +       socks = __rcu_dereference_sk_user_data_cond(sk, SK_USER_DATA_BPF);
> > +       if (socks) {
> >                 WRITE_ONCE(sk->sk_user_data, NULL);
> >                 /*
> >                  * Do not move this NULL assignment outside of
> >
> >
> > But that must be a separate patch, not part of this fix.
I wonder if it is proper to gather these together in a patchset, for
they are all about flags in sk_user_data, maybe:

[PATCH v5 0/2] net: enhancement to flags in sk_user_data field
	- introduce the patchset

[PATCH v5 1/2] net: clean up code for flags in sk_user_data field
	- refactor the things in include/linux/skmsg.h and
include/net/sock.h
	- refactor the flags's usage by other code, such as
net/core/skmsg.c and kernel/bpf/reuseport_array.c

[PATCH v5 2/2] net: fix refcount bug in sk_psock_get (2)
	- add SK_USER_DATA_PSOCK flag in sk_user_data field

  reply	other threads:[~2022-08-04  3:07 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-03 15:34 [syzbot] WARNING: refcount bug in sk_psock_get (2) syzbot
2022-07-09  2:46 ` [PATCH] smc: fix " Hawkins Jiawei
2022-07-09  3:06   ` Jakub Kicinski
2022-07-09  8:36     ` Hawkins Jiawei
2022-07-11  7:21   ` Wen Gu
2022-07-13  3:10     ` Hawkins Jiawei
2022-07-13  3:33       ` Jakub Kicinski
2022-07-13  3:53         ` Hawkins Jiawei
2022-07-12  9:47   ` Dan Carpenter
2022-07-13  3:35     ` Hawkins Jiawei
2022-07-30  8:56 ` [PATCH v2] net/smc: " Hawkins Jiawei
2022-08-01  9:09   ` Jakub Sitnicki
2022-08-02 14:32     ` Hawkins Jiawei
2022-08-03  8:03 ` [PATCH v3] " Hawkins Jiawei
2022-08-03 11:27   ` Wen Gu
2022-08-03 12:07     ` Hawkins Jiawei
2022-08-03 12:41 ` [PATCH v4] net: " Hawkins Jiawei
2022-08-03 15:14   ` Jakub Kicinski
2022-08-03 15:37     ` Martin KaFai Lau
2022-08-04  3:05       ` Hawkins Jiawei [this message]
2022-08-04 15:29         ` Jakub Kicinski
2022-08-05  6:28           ` Hawkins Jiawei
2022-08-05  7:36 ` [PATCH net v5 0/2] net: enhancements to sk_user_data field Hawkins Jiawei
2022-08-05  7:48   ` [PATCH net v5 1/2] net: fix refcount bug in sk_psock_get (2) Hawkins Jiawei
2022-08-05  7:48   ` [PATCH net v5 2/2] net: refactor bpf_sk_reuseport_detach() Hawkins Jiawei
2022-08-15 18:24     ` Martin KaFai Lau
2022-08-05 10:29   ` [PATCH net v5 0/2] net: enhancements to sk_user_data field Jakub Sitnicki
2022-08-05 15:36     ` Hawkins Jiawei
2022-08-11  5:30   ` 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=20220804030514.7118-1-yin31149@gmail.com \
    --to=yin31149@gmail.com \
    --cc=18801353760@163.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=borisp@nvidia.com \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=guwen@linux.alibaba.com \
    --cc=jakub@cloudflare.com \
    --cc=john.fastabend@gmail.com \
    --cc=kafai@fb.com \
    --cc=kgraul@linux.ibm.com \
    --cc=kpsingh@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel-mentees@lists.linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=paskripkin@gmail.com \
    --cc=skhan@linuxfoundation.org \
    --cc=songliubraving@fb.com \
    --cc=syzbot+5f26f85569bd179c18ce@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.com \
    --cc=yhs@fb.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).