All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@ziepe.ca>
To: Serhat Kumral <serhatkumral1@gmail.com>
Cc: Leon Romanovsky <leon@kernel.org>,
	Zhu Yanjun <yanjun.zhu@linux.dev>,
	Zhu Yanjun <zyjzyj2000@gmail.com>,
	David Ahern <dsahern@kernel.org>,
	linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org,
	syzbot+8c9eede336e3a843750e@syzkaller.appspotmail.com
Subject: Re: [RFC PATCH 1/2] RDMA/rxe: drive UDP tunnel socket lifetime from the GID table
Date: Sat, 18 Jul 2026 12:39:27 -0300	[thread overview]
Message-ID: <20260718153927.GF701389@ziepe.ca> (raw)
In-Reply-To: <20260718142642.102924-1-serhatkumral1@gmail.com>

On Sat, Jul 18, 2026 at 05:26:41PM +0300, Serhat Kumral wrote:
> I first tried the literal reading, one bound socket per GID entry,
> but real addresses get in the way: default GIDs derived from the MAC
> are not bindable addresses, IPv6 GIDs are added while still tentative
> so bind() fails and nothing re-adds them after DAD, and multicast RX
> cannot match address-bound sockets. So this version keeps the
> wildcard sockets as they are today and only moves their lifetime to
> add_gid/del_gid, which is where the actual bugs were.

That is unfortunate, but this still a big step forward.

FWIW the tx side also looks really weird, it creates a sock per QP in
the init_net but that can't be right. It seems to me it should be
sending using the per-GID socket instead.. That's nothing to do with
this series though

> The pernet exit hook survives in a reduced form, as a backstop only:
> event-triggered GID removal is asynchronous, so a netns can be gone
> before the last del_gid runs (most easily by moving the netdev to
> another netns and deleting the old one), and something has to close
> the kernel sockets before the net they live in is freed. 

Don't get this, GID removal is asynchronous, so it will eventually
complete, what is wrong with leaving the socks around but unsuable for
a little bit? Does something break?

Jason

  parent reply	other threads:[~2026-07-18 15:39 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-18 14:26 [RFC PATCH 1/2] RDMA/rxe: drive UDP tunnel socket lifetime from the GID table Serhat Kumral
2026-07-18 14:26 ` [RFC PATCH 2/2] RDMA/nldev: remove the unused dellink link op Serhat Kumral
2026-07-18 15:39 ` Jason Gunthorpe [this message]
2026-07-18 16:01 ` [RFC PATCH 1/2] RDMA/rxe: drive UDP tunnel socket lifetime from the GID table Zhu Yanjun
2026-07-18 16:04   ` Jason Gunthorpe
2026-07-19  5:08 ` Zhu Yanjun

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=20260718153927.GF701389@ziepe.ca \
    --to=jgg@ziepe.ca \
    --cc=dsahern@kernel.org \
    --cc=leon@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=serhatkumral1@gmail.com \
    --cc=syzbot+8c9eede336e3a843750e@syzkaller.appspotmail.com \
    --cc=yanjun.zhu@linux.dev \
    --cc=zyjzyj2000@gmail.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 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.