From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f182.google.com (mail-qk1-f182.google.com [209.85.222.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 083563D0C16 for ; Sat, 18 Jul 2026 15:39:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784389179; cv=none; b=fSsQ0BzmdllCWLc4j883E9qrs75FW/Q1ITu6/s7B/BOeBZh5EHOMm8w0EJhIax5BwN+o1BrjKKCVDWvmg1GwWe8FpHp1WnyvODWNn3LEGGHLO1mmvtB4m6ainpClvkMGfpXNHsycAMDRSdlyMsB6sxT3b0Vo59I0kWDwvITgrWc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784389179; c=relaxed/simple; bh=w/cQSSJw+CwXZdc2ipK0ZWSqiyw6IFQdC7x01sXck00=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=EUBNsi5aq5ChMfSlZGjmChIoM1rPOAOqgRCdC+urfX/3hLGUKLnNWo16BTNYQb4C+PTEOnU2DlH8v85y7lvanCZnhg1UHBBN3LxoznwCMZ/Sm0kmILfXgdt4X5EIbqp8wKU2dYiTj53yZRqkhDx5xEGnUdCr3EYUmq6oPdtVyxc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca; spf=pass smtp.mailfrom=ziepe.ca; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b=Qt2742rv; arc=none smtp.client-ip=209.85.222.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="Qt2742rv" Received: by mail-qk1-f182.google.com with SMTP id af79cd13be357-92e65e18969so265875385a.1 for ; Sat, 18 Jul 2026 08:39:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1784389168; x=1784993968; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=tUgLi2+x5V7Fq31NyBOiMexpXFIl8ZrVq5R+BsxDVFg=; b=Qt2742rv7tCLsL+dvpVYlrQqJ0xS+7k2IhaE4PUxgmYBegt3jJndWIzU5SJ/ZUQCO7 AUbucSpRHpFJ2s57obnuzRIJoGGcbSqUwz0920x1im7MHELUUWAaSkFVP5qpnl0FMIhJ 5/EEHG8Wcays/d5M+DzNIVZyPA0alKM/jP1HwR3UvQrBTkczHz2BReWHx2BSsDYh4nCJ XwCTljSPn1oJlluD7Z/TK76fzHTi2VpQlPQke0P5Iw8zuZw39rr7m+3dg1uvTmeV6n2H loQvGJD8WcR7kCKLiHHbVnxV+6rkW62CP/WtqIHlX5eKUk5RxPrTmPvSgZ4UyS9apngq QFkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784389168; x=1784993968; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=tUgLi2+x5V7Fq31NyBOiMexpXFIl8ZrVq5R+BsxDVFg=; b=tJMVcv41DObbxrYQjzBXJ5Of6Mwy3QDN4Ej0b/8DgblnbFW2mwGZUkrcvEv1VoAaMG h2IcarYVlcqoMLgseu6Q0N10+qtjiqac6E7n8Zk6+j+4ypQMFWTIe/6Nsyyan7oS6b5h ThQ4AVzIgyfA5jHvlYrIGxee/k3X8p9wE3cq10YT7/y+irHIgJNezCZ9X1gDpK7xPQuA MqAWiv1hHWARvOTj4f78Ih0GjLJvewalsQvZJVD2jCsggAPHwck7Z4vjrwfo4gs6KfB/ 33HvtP5HXbY/EGPEzVmXMcM2SBPJqkm8UeuTXflEESxWdg1Kux76RLb3l3vgG3p14mv2 8AqQ== X-Forwarded-Encrypted: i=1; AHgh+RoXOjTEt6lkrR3pHA4SaAyml69gAPPm9X7lhp7/jKCbUXyCx6scGLsNaQ/3PNd+I2HkQg3JgoUmSRUXDc8=@vger.kernel.org X-Gm-Message-State: AOJu0YwcMnUbCoqu/g84AHpB938fOPYupwxZkHt0PUU+c2H92nkqn3/6 RebLCmjIbWEepSDecl1EuCLYLiZjgT6ExHItk1JpdMVzbfUHzPX/iKpCZK7dfFpLuu8= X-Gm-Gg: AfdE7clOzJW8BfSCI6eDEpJJwrEhPgvnsM/A721YboeSAZVizgqhSEXLGxQ+U3m1s4u 16EwZMi10f6caYdGbw0mA4uETqMqO4JVdBHD5Hsy0UdX51O0Qa614mqvN6X8N87V7ZOGQNXlKcC MAPUSdgZCUz668yJSG55JgI6MalGLcGGwzZhKEdwkC21+1uCNY8l0wqCidbKgLy4WJaHeLqtkG8 3B6xu5gb0Ll2drBjdWXo79bRrn6m7MzltG59gTB5Vc3yyoAccG0VLBA9EDZVsuyDu6iemE9zHdf GQIm/Lsq1OMiJCTmhJysksubshjPg3THYe1UBbq6L+u/jZbTiDBjugMKff46U5y4kcHOweG7llN 9s3vMP23rRszRpWnfAtc+qe5LOCtsLf8xx7Hm/8S/c4ROLttR/g== X-Received: by 2002:a05:620a:45a4:b0:915:e426:8198 with SMTP id af79cd13be357-930b48654d2mr746661585a.15.1784389168217; Sat, 18 Jul 2026 08:39:28 -0700 (PDT) Received: from ziepe.ca ([159.2.72.92]) by smtp.gmail.com with ESMTPSA id af79cd13be357-930b52fa8dfsm430088085a.11.2026.07.18.08.39.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 18 Jul 2026 08:39:27 -0700 (PDT) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1wl78R-00000006Ycv-0IpF; Sat, 18 Jul 2026 12:39:27 -0300 Date: Sat, 18 Jul 2026 12:39:27 -0300 From: Jason Gunthorpe To: Serhat Kumral Cc: Leon Romanovsky , Zhu Yanjun , Zhu Yanjun , David Ahern , 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 Message-ID: <20260718153927.GF701389@ziepe.ca> References: <20260718142642.102924-1-serhatkumral1@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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