From: Hawkins Jiawei <yin31149@gmail.com>
To: jakub@cloudflare.com
Cc: songliubraving@fb.com, guvenc@linux.ibm.com, ast@kernel.org,
edumazet@google.com, linux-s390@vger.kernel.org,
daniel@iogearbox.net, davem@davemloft.net, borisp@nvidia.com,
paskripkin@gmail.com, john.fastabend@gmail.com,
andrii@kernel.org, kuba@kernel.org, pabeni@redhat.com,
linux-kernel-mentees@lists.linuxfoundation.org,
syzbot+5f26f85569bd179c18ce@syzkaller.appspotmail.com,
ubraun@linux.ibm.com, syzkaller-bugs@googlegroups.com,
kpsingh@kernel.org, wenjia@linux.ibm.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, kgraul@linux.ibm.com, yhs@fb.com,
guwen@linux.alibaba.com, yin31149@gmail.com, bpf@vger.kernel.org,
kafai@fb.com
Subject: Re: [PATCH v2] net/smc: fix refcount bug in sk_psock_get (2)
Date: Tue, 2 Aug 2022 22:32:14 +0800 [thread overview]
Message-ID: <20220802143214.5885-1-yin31149@gmail.com> (raw)
In-Reply-To: <87wnbsjpdb.fsf@cloudflare.com>
Thanks for your suggestion!
On Mon, 1 Aug 2022 at 17:16, Jakub Sitnicki <jakub@cloudflare.com> wrote:
> This way we would also avoid some confusion. With the change below, the
> SK_USER_DATA_NOTPSOCK is not *always* set when sk_user_data holds a
> non-psock pointer. Only when SMC sets it.
>
> If we go with the current approach, the rest of sites, execpt for psock,
> that assign to sk_user_data should be updated to set
> SK_USER_DATA_NOTPSOCK as well, IMO.
Yes, as you point out, in this patch, this flag's name should be
*SK_USER_DATA_NEEDCHECK_NOTPSOCK*, which is more clearly.
To be more specific, we don't need to set this flag for
every sk_user_data who holds non-psock pointer. Only set the flag for
the site that has been reported involved with the type-mismatch bug
like this bug.
> > During SMC fallback process in connect syscall, kernel will
> > replaces TCP with SMC. In order to forward wakeup
> > smc socket waitqueue after fallback, kernel will sets
> > clcsk->sk_user_data to origin smc socket in
> > smc_fback_replace_callbacks().
> >
> > Later, in shutdown syscall, kernel will calls
> > sk_psock_get(), which treats the clcsk->sk_user_data
> > as sk_psock type, triggering the refcnt warning.
For other sites, this patch is actually transparent to them, because
the *SK_USER_DATA_NEEDCHECK_NOTPSOCK* flag is always unset. So this
patch won't affect them, which won't introduce any extra
potential bugs.
> +/**
> + * rcu_dereference_sk_user_data_psock - return psock if sk_user_data points
> + * to the psock
> + * @sk: socket
> + */
> +static inline
> +struct sk_psock *rcu_dereference_sk_user_data_psock(const struct sock *sk)
> +{
> + uintptr_t __tmp = (uintptr_t)rcu_dereference(__sk_user_data((sk)));
> +
> + if (__tmp & SK_USER_DATA_NOTPSOCK)
> + return NULL;
> + return (struct sk_psock *)(__tmp & SK_USER_DATA_PTRMASK);
> +}
>
> Hi,
> Since using psock is not the common case, I'm wondering if it makes more
> sense to have an inverse flag - SK_USER_DATA_PSOCK. Flag would be set by
> the psock code on assignment to sk_user_data.
However, your suggestion seems more elegant. For my patch, as you point
out, when anyone reports a new type-mismatch bug, the relative assign to
sk_user_data should be updated to set *SK_USER_DATA_NEEDCHECK_NOTPSOCK*
flag.
For your suggestion, you seems avoid above situation. What's more, as I
use git grep to search, there seems no direct access to sk_user_data,
all via a small amount macros and wrapper functions. So we can keep
transparent by only update those macros and wrapper functions, which
also won't introduce any extra potential bugs.
I will patch as you suggest in v3 patch.
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
next prev parent reply other threads:[~2022-08-02 14:32 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <00000000000026328205e08cdbeb@google.com>
2022-07-09 2:46 ` [PATCH] smc: fix refcount bug in sk_psock_get (2) 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 via Linux-kernel-mentees
2022-08-02 14:32 ` Hawkins Jiawei [this message]
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 via Linux-kernel-mentees
2022-08-04 3:05 ` Hawkins Jiawei
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 via Linux-kernel-mentees
2022-08-05 10:29 ` [PATCH net v5 0/2] net: enhancements to sk_user_data field Jakub Sitnicki via Linux-kernel-mentees
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=20220802143214.5885-1-yin31149@gmail.com \
--to=yin31149@gmail.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=guvenc@linux.ibm.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=linux-s390@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=paskripkin@gmail.com \
--cc=songliubraving@fb.com \
--cc=syzbot+5f26f85569bd179c18ce@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
--cc=ubraun@linux.ibm.com \
--cc=wenjia@linux.ibm.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).