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