Re: [PATCH 5.10 35/79] tcp: Add num_closed_socks to struct sock_reuseport.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Oct 27, 2022 at 12:53:49PM -0700, Kuniyuki Iwashima wrote:
> Hi Greg, Sasha,
> 
> From:   Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
> Date:   Thu, 27 Oct 2022 18:55:45 +0200
> > From: Kuniyuki Iwashima <kuniyu@xxxxxxxxxxxx>
> > 
> > [ Upstream commit 5c040eaf5d1753aafe12989ca712175df0b9c436 ]
> > 
> > As noted in the following commit, a closed listener has to hold the
> > reference to the reuseport group for socket migration. This patch adds a
> > field (num_closed_socks) to struct sock_reuseport to manage closed sockets
> > within the same reuseport group. Moreover, this and the following commits
> > introduce some helper functions to split socks[] into two sections and keep
> > TCP_LISTEN and TCP_CLOSE sockets in each section. Like a double-ended
> > queue, we will place TCP_LISTEN sockets from the front and TCP_CLOSE
> > sockets from the end.
> > 
> >   TCP_LISTEN---------->       <-------TCP_CLOSE
> >   +---+---+  ---  +---+  ---  +---+  ---  +---+
> >   | 0 | 1 |  ...  | i |  ...  | j |  ...  | k |
> >   +---+---+  ---  +---+  ---  +---+  ---  +---+
> > 
> >   i = num_socks - 1
> >   j = max_socks - num_closed_socks
> >   k = max_socks - 1
> > 
> > This patch also extends reuseport_add_sock() and reuseport_grow() to
> > support num_closed_socks.
> > 
> > Signed-off-by: Kuniyuki Iwashima <kuniyu@xxxxxxxxxxxx>
> > Signed-off-by: Daniel Borkmann <daniel@xxxxxxxxxxxxx>
> > Reviewed-by: Eric Dumazet <edumazet@xxxxxxxxxx>
> > Acked-by: Martin KaFai Lau <kafai@xxxxxx>
> > Link: https://lore.kernel.org/bpf/20210612123224.12525-3-kuniyu@xxxxxxxxxxxx
> > Stable-dep-of: 69421bf98482 ("udp: Update reuse->has_conns under reuseport_lock.")
> > Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>
> 
> I think this patch is backported due to a conflict with the cited commit
> 69421bf98482 ("udp: Update reuse->has_conns under reuseport_lock.").
> 
> The following patch seems to conflicts with some functions which are
> introduced in this patch, but the cited commit does not depend on the
> functions.
> 
> So, we can just remove the functions in this patch and resolve the
> conflict in the next patch like below. (based on the v5.10.150 branch)

so drop this "dependent" patch and just take your backport instead?

confused,

greg k-h



[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux