All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Wen Gu <guwen@linux.alibaba.com>
Cc: stable@vger.kernel.org, alikernel-developer@linux.alibaba.com,
	Dust Li <dust.li@linux.alibaba.com>,
	"D. Wythe" <alibuda@linux.alibaba.com>,
	mqaio@linux.alibaba.com
Subject: Re: Please backport d8616ee2affc ("bpf, sockmap: Fix sk->sk_forward_alloc warn_on in sk_stream_kill_queues") to linux-5.10.y
Date: Tue, 2 Jul 2024 10:23:58 +0200	[thread overview]
Message-ID: <2024070225-dictation-rebuff-be4b@gregkh> (raw)
In-Reply-To: <d11bc7e6-a2c7-445a-8561-3599eafb07b0@linux.alibaba.com>

On Sun, Jun 30, 2024 at 08:55:56PM +0800, Wen Gu wrote:
> 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/)

As there is fuzz with this patch, please send a backported, and tested,
version of this patch so we can include it and properly show who it was
requested from.

thanks,

greg k-h

      parent reply	other threads:[~2024-07-02  8:24 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-30 12:55 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  2:07 ` Wen Gu
2024-07-02  8:22   ` Greg KH
2024-07-02 12:55     ` Wen Gu
2024-07-02  8:23 ` Greg KH [this message]

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=2024070225-dictation-rebuff-be4b@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=alibuda@linux.alibaba.com \
    --cc=alikernel-developer@linux.alibaba.com \
    --cc=dust.li@linux.alibaba.com \
    --cc=guwen@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.