From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f52.google.com (mail-qv1-f52.google.com [209.85.219.52]) (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 8911443CEF0 for ; Thu, 5 Feb 2026 17:25:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770312323; cv=none; b=S1FeYKSJwbFDGxEAKNLUBuOxjW7WiQloaH8TI/h5vUVg+e5oTff1/+vtAPvpFSQXyZirxnwQrlIouX1XXfhvbe26j/oYya65UNyy9LBHoPg5Opg0TTv9pEsbOQg56VTnXLSimTn1u61/0jGCAK5/0eUHbdoLTpQptwEhjcgTN4o= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770312323; c=relaxed/simple; bh=QU2IJIK2vmP13Zf6DmZLFuW4MJXbJ0esgfIqUAfugJM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=k0i2v23/v+HGxrRt9Z1OdTPbafl+Lzz8kaeEpWfqC5obnssRVq1j87La25kE1DB/OxAQ2iBtkd+vLOfH8wItPgLMZtRmQRQu9o0JBHBhw9oJi3yMnyR22SqduZsgnh06Jja52SxOHP7gPdytitOh+q+Y4/fDxbtbEFFunmFT4+k= 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=BUHh307p; arc=none smtp.client-ip=209.85.219.52 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="BUHh307p" Received: by mail-qv1-f52.google.com with SMTP id 6a1803df08f44-8887ac841e2so10306616d6.2 for ; Thu, 05 Feb 2026 09:25:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1770312322; x=1770917122; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=X5GoqZEI5t00UC7KZJgq0tM/XLi5xv+p4t430jlWtHs=; b=BUHh307pE5mervPCCSLL3I4hIUiK2QbjjVZimhWgC2/JziKuE9UgE354ojnNf09v1z pXlQiBbos9asteln11Gj0CrL5vDhHa85PkCeSyeduu4rK+lqGevXGWJh7Unle2dwrRxD wi2OJRKZ1YsuX5FCAQsn6TWC97z/LpwAbqE9GO2s4T+rpBcEN9hiO2Oxh9exQJeFMjmM r3EVkFB6gkQLLfl0Mtnif6bvXWcPsVpjHsnzHSXPum6mfTGR2LR61jpvqDNg9OKh3k8S UANb7tE2R9P0431q2Ie7/lBltYg+E7l7QzWnReKOKXebu524dPOjL4bLwSkkwIU7aP0k vI9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770312322; x=1770917122; h=in-reply-to:content-disposition: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; bh=X5GoqZEI5t00UC7KZJgq0tM/XLi5xv+p4t430jlWtHs=; b=YthPSNLMNFEqdhvknmksdjJVVRf3hp/557YvVnEWDVd97erCdhZYdbgTgprc/PxRHu i4wScW08+nQ/Ukn4LWu7R2vzWcDuJH21qgoBc5DHfE0A9Ca/6UORyknq4TH0LBXZLTS5 qciJovNUl4i37/vpyIc2ymdUBK0Ey5YRhbmMUp0T7DjVekqRf71lQoS+OOXyj0De5hcf yhTvoLnqFkgQSC4P72LXscId74eo9TzecNIr8/9GVACdupbfcCWhaS6UVGGtEYrV5Snj ohu8/K93B9UKOi43rKbz3afVThVZjsML1an1hI4P453gTa8gPh0mHUa5dem7J8KQokBN o0aQ== X-Forwarded-Encrypted: i=1; AJvYcCXaASfozahmVqh82l7sRQTudIscBNp6PSgWlu8sBmvXuFnYTCSdZhyJZW2HO02YXYpH1SJpQ+o/OwlLNko=@vger.kernel.org X-Gm-Message-State: AOJu0YxNGnc5i60b7rXX6WZcZ8nxoPiitLVtg9uO4GAXMHu6qAIyF2iu /vPn8hFLU61M1pbTaIxbZs1O8vx9DSF7SRHdizSjScLkjWPp2lBA58eqfS/G0rRuRl5TbRTnFPS Fk3EU X-Gm-Gg: AZuq6aJDW6/R/EcZR0ewZQKc9ZbaUYxdem4lWD6lFUbbrzTQ0qgexX5JNiJ5jcHZJbk xEA/15QoCsoAk8KERqFJekNHwqkc8bgp2S1JX+FEkxsV7o7RMvxY4tPd8OIh+lq9MTRkVQ6/8I+ kndJFq6BzOOBanvVbmYY5djFAXJ7VL15J0WWMgSL9NEVRBDhRjS0vvtYTBOxYmkD1xCGy38BME1 8qD5S5LXl9QXdpm3a5D1mHQWHC8o8S9evq1EBaSYJVxmelq/RKpGfyamzOumd41gh4d+9+DWp+3 LVM4vd1q9SkHOB1/Zuau8fO5Bmx4IiUBCEStQleuOFq1XgfUsff875N4kSxuQRwNSC4Z8WQ8cST U9KhjrDS5A8enHGrVyHAjNV1B2FTRXyubUdcJ97IliwmFH7DINYlU5axtvvpp4/G82fxjsbVDoV GuOhxBeHl51x6/Nn9jroOPOSRy0eWQuwdAFjglgu0NOunWowVyxF6jS7RPESoJ0InHCcJaJkR/N VTIBg== X-Received: by 2002:a05:6214:c2d:b0:895:3ad:a628 with SMTP id 6a1803df08f44-8952210b0a8mr113153096d6.14.1770312322300; Thu, 05 Feb 2026 09:25:22 -0800 (PST) Received: from ziepe.ca (hlfxns017vw-142-162-112-119.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.162.112.119]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-8953bf38426sm328126d6.12.2026.02.05.09.25.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Feb 2026 09:25:21 -0800 (PST) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1vo36X-00000001ndM-1Aaf; Thu, 05 Feb 2026 13:25:21 -0400 Date: Thu, 5 Feb 2026 13:25:21 -0400 From: Jason Gunthorpe To: Konstantin Taranov Cc: Konstantin Taranov , Shiraz Saleem , Long Li , "leon@kernel.org" , "linux-rdma@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH rdma-next v2 1/1] RDMA/mana_ib: return PD number to the user Message-ID: <20260205172521.GN2328995@ziepe.ca> References: <20260205121354.925515-1-kotaranov@linux.microsoft.com> <20260205142212.GL2328995@ziepe.ca> 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: On Thu, Feb 05, 2026 at 04:35:44PM +0000, Konstantin Taranov wrote: > > > On Thu, Feb 05, 2026 at 04:13:54AM -0800, Konstantin Taranov wrote: > > > From: Konstantin Taranov > > > > > > Implement returning to userspace applications PDNs of created PDs. > > > The PDN is used by applications that build work requests outside of > > > the rdma-core code base. The PDN is used to build work requests that > > > require additional PD isolation checks. The requests can fit only 16 bit > > PDNs. > > > Allow users to request short PDNs which are 16 bits. > > > > What? > > > > PDN is protected information it should never be given to the HW directly > > from userspace. > > > > How can this possibly be secure? > > As far as I know, it is secure as classical PD check for WQ exists and it is just some > additional requirement to mention PDN in a request. If all you are doing is sending a PDN in a WQ that must always match that PDN that the WQ already has then I would agree that is OK. But a completely nonsensical thing to do - to the point I'm skeptical that it is actually being validated ??? > I am not the one who created this requirement to mention PDN in the > request, but I got an ask to expose that since some vendors do that, > and there were no security concerns (see struct mlx5dv_pd from > mlx5dv_init_obj()). That's different, that is going through a FW path and mlx5 has a UID mechanism to link the permitted PDN to the user making the request. > It seems is not a concern when > the PDN is set from user-space into the address vector (see fill_ud_av() from hns, > mlx4_create_ah(). and mthca_alloc_av()). As far as I understand, the use-case > aimed here is similar to address vectors. All these AH cases all end up with checks in SW or HW that the PDN is valid for the context. What you are describing could be real, but is so hard to accept that I'm going to ask you to strongly verify it and document all this in the commit message. Jason