From: Wen Gu <guwen@linux.alibaba.com>
To: stable@vger.kernel.org
Cc: alikernel-developer@linux.alibaba.com,
Wen Gu <guwen@linux.alibaba.com>,
Dust Li <dust.li@linux.alibaba.com>,
"D. Wythe" <alibuda@linux.alibaba.com>,
mqaio@linux.alibaba.com
Subject: Please backport d8616ee2affc ("bpf, sockmap: Fix sk->sk_forward_alloc warn_on in sk_stream_kill_queues") to linux-5.10.y
Date: Sun, 30 Jun 2024 20:55:56 +0800 [thread overview]
Message-ID: <d11bc7e6-a2c7-445a-8561-3599eafb07b0@linux.alibaba.com> (raw)
Hi stable team,
Could you please backport [1] to linux-5.10.y?
I noticed a regression caused by [2], which was merged to linux-5.10.y since v5.10.80.
After sock_map_unhash() helper was removed in [2], sock elems added to the bpf sock map
via sock_hash_update_common() cannot be removed if they are in the icsk_accept_queue
of the listener sock. Since they have not been accept()ed, they cannot be removed via
sock_map_close()->sock_map_remove_links() either.
It can be reproduced in network test with short-lived connections. If the server is
stopped during the test, there is a probability that some sock elems will remain in
the bpf sock map.
And with [1], the sock_map_destroy() helper is introduced to invoke sock_map_remove_links()
when inet_csk_listen_stop()->inet_child_forget()->inet_csk_destroy_sock(), to remove the
sock elems from the bpf sock map in such situation.
[1] d8616ee2affc ("bpf, sockmap: Fix sk->sk_forward_alloc warn_on in sk_stream_kill_queues")
(link: https://lore.kernel.org/all/20220524075311.649153-1-wangyufen@huawei.com/)
[2] 8b5c98a67c1b ("bpf, sockmap: Remove unhash handler for BPF sockmap usage")
(link: https://lore.kernel.org/all/20211103204736.248403-3-john.fastabend@gmail.com/)
Thanks!
Wen Gu
next reply other threads:[~2024-06-30 12:56 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-30 12:55 Wen Gu [this message]
2024-07-02 2:07 ` Please backport d8616ee2affc ("bpf, sockmap: Fix sk->sk_forward_alloc warn_on in sk_stream_kill_queues") to linux-5.10.y Wen Gu
2024-07-02 8:22 ` Greg KH
2024-07-02 12:55 ` Wen Gu
2024-07-02 8:23 ` Greg KH
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=d11bc7e6-a2c7-445a-8561-3599eafb07b0@linux.alibaba.com \
--to=guwen@linux.alibaba.com \
--cc=alibuda@linux.alibaba.com \
--cc=alikernel-developer@linux.alibaba.com \
--cc=dust.li@linux.alibaba.com \
--cc=mqaio@linux.alibaba.com \
--cc=stable@vger.kernel.org \
/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.