From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yw1-f194.google.com (mail-yw1-f194.google.com [209.85.128.194]) (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 5F59C2FAC12 for ; Tue, 27 Jan 2026 03:06:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.194 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769483213; cv=none; b=Upgg1QYgZrncgu1aOxEik2yjpA+7YKZGmCnda881u5g8Sq8Zg8mOizkU3QJ7q/xx4FZXlQmWYR/gNA4jATbjPY8nMcGtcbvH8/63COSFrADaa8ALrGQJ4z3YEQNbyaS2wvbOikokXzPgzlfB7sOmrthmtxydd9WQLstCp6mqAG0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769483213; c=relaxed/simple; bh=wYEcUgNuD+lPf2tV7/btjfFjqrI60S+N7nj/8yNW7Xo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=cb8PfMvaAQnfOXbBjFq2kNNpnekv1JuNs3Svg7op0cMZATEn1kqGPM42YGT/DMrsSA+UeDHLPuutXreEz/195bPBGbtdWpqmwYQydim8pw51TjXiupNixhZZhtoGEdLTEVlOuoc4aMgo/zLq3y+tdzx/7eyaqArLKETQ5LR0F8g= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=IU47TRk1; arc=none smtp.client-ip=209.85.128.194 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="IU47TRk1" Received: by mail-yw1-f194.google.com with SMTP id 00721157ae682-79478ec4cf1so2125627b3.3 for ; Mon, 26 Jan 2026 19:06:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769483211; x=1770088011; 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=XtcTamun/anyrF+4xJBkkNRqAbEPEhjvU9VCmmVXBeM=; b=IU47TRk1K97pPGLqScYNmy4ieeG4lxxAnlN6s9T5ZO8WFpCbaJanHJru4scZJ/CbVl SmKDr9/06OWQzItbsOcZI+uuqTGVB015Uq996Jb2kNYlwbiOMYACKf7wpL7on99kakp8 H415wOaurydKRZ4sP9l2enHfr+aDhBIQLMuW4lazcPnGyJSzVcerSo7WtZbSYgxzA2Oa QO4OHhOH+mGDtYKpF+GBlnJl7CLwjkiQn5iSJ+HXjjPExlu8ajNLuurTzkaoirbPsbtK DlHwskRWVw1SXw5/65rCtlEOiLMAt1gKOqNEs+NzjdM4s9c5TnNXAnoeWZKbrmDCYpXH NxdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769483211; x=1770088011; 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=XtcTamun/anyrF+4xJBkkNRqAbEPEhjvU9VCmmVXBeM=; b=T2ou/IJi6NjuUywamEVzGna/l26sFUgsZWuaFA7rft+BXSE6XGQpBenAA1fcJHXs5b TxbbLpt9fERN5qyf00YFNA1rb9qr0YlAPLAk2kyvcsTOLe4xXfxSZhtIOaJJIx9ipSj1 Ev7mW3u7QDgXifoQ2lOtA0Zfecadb5haR0E/258rOvOVVqjiNPN7WFMVYtARDuCmMj5h Y8SOqSFws9Mo1iDEglAqrlPGDXfPWtLLn+IAENNzQJ6X2Y3EJZS6zZxRVufSWsN5rTWL tRmbiUZynZrOMmbFG5koXHWuLf60G2w2mY7vLEPDI1z5NGnX8Dj/m+GqZwlYAfy6C8VC iJ5w== X-Forwarded-Encrypted: i=1; AJvYcCUnZf5Nmo7cLa3Ty71hxHePQPOJY3HsyrKyLI98L5qBOHY21D1t7HwtwPIAXZGX8rHlh3BDupIqVsTVYi4=@vger.kernel.org X-Gm-Message-State: AOJu0Yx8n33QiuzR5Sie9EkJGaX47/8NbTIiBTzBMZhlWV9AiUdPP9eu /5/T/K1W1BWk4p+LtCoIixIrxbO5jUFPn/MhA32+I+06gJ5HIgKkv/n4 X-Gm-Gg: AZuq6aLoTZjFyik7teRnqTSudlbaZtj9NWz8jC77N5DtcdDuEZTq5xalKko1KbhQOxX XV04d+Cks8jfmY3TRGzunrVwrpoYhMmrMrMA9cnVxYtxR3gV/ICGhvAhI9V3kcCkd6dNM9nMc49 oKZxGeLuIQZVnl/3lZfYqrksdUymXzipLtPDmGqd2xS3QUP9f432qWs3HM9kIxzzNjniaIH/xcp vsphOJ748YIlMD1d4hTtYCHP478v+v1sGY1I4LBIoa1p8AJIxfmcJAPouQ5Q29g0L5L7YeXYcrg 6RnYsEVecBicCNEdiM+xKI1O3y55+5zK7AclvPnfBh0jGIbQO4eRMWiwfCyL5ClIkIUYJlQcvQF SxSLhle7tAEp76tzPkDz66xtNMedaFJ8TiJlqARjq/FGuVhvAx5MrQqPLnL2+BYoH42fhTmHRlK Wf/oIRlPHPxSBZGELYo6q3Q8apY1UaBeiHag== X-Received: by 2002:a05:690c:f02:b0:786:7a54:4635 with SMTP id 00721157ae682-7947ab3c172mr1656687b3.21.1769483211400; Mon, 26 Jan 2026 19:06:51 -0800 (PST) Received: from devvm11784.nha0.facebook.com ([2a03:2880:25ff:5::]) by smtp.gmail.com with ESMTPSA id 00721157ae682-79475c0212asm5994517b3.2.2026.01.26.19.06.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Jan 2026 19:06:51 -0800 (PST) Date: Mon, 26 Jan 2026 19:06:49 -0800 From: Bobby Eshleman To: Jakub Kicinski Cc: Stanislav Fomichev , "David S. Miller" , Eric Dumazet , Paolo Abeni , Simon Horman , Kuniyuki Iwashima , Willem de Bruijn , Neal Cardwell , David Ahern , Mina Almasry , Arnd Bergmann , Jonathan Corbet , Andrew Lunn , Shuah Khan , Donald Hunter , Stanislav Fomichev , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org, asml.silence@gmail.com, matttbe@kernel.org, skhawaja@google.com, Bobby Eshleman Subject: Re: [PATCH net-next v10 4/5] net: devmem: document NETDEV_A_DMABUF_AUTORELEASE netlink attribute Message-ID: References: <20260121173512.748e2155@kernel.org> <20260121185021.446b00e8@kernel.org> <20260121194615.33dc0812@kernel.org> <20260126172646.2e5af2d4@kernel.org> <20260126184440.755a55b2@kernel.org> 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: <20260126184440.755a55b2@kernel.org> On Mon, Jan 26, 2026 at 06:44:40PM -0800, Jakub Kicinski wrote: > On Mon, 26 Jan 2026 18:30:45 -0800 Bobby Eshleman wrote: > > > > I'm not a fan of the existing cmsg scheme, but we already have userspace > > > > using it, so getting more performance out of it seems like an easy win? > > > > > > I don't like: > > > - the fact that we have to add the binding to a socket (extra field) > > > - single socket can only serve single binding, there's no technical > > > reason for this really, AFAICT, just the fact that we have a single > > > pointer in the sock struct > > > > The core reason is that sockets lose the ability to map a given token to > > a given binding by no longer storing the niov ptr. > > > > One proposal I had was to encode some number of bits in the token that > > can be used to lookup the binding in an array, I could reboot that > > approach. > > > > With 32 bits, we can represent: > > > > dmabuf max size = 512 GB, max dmabuf count = 8 > > dmabuf max size = 256 GB, max dmabuf count = 16 > > dmabuf max size = 128 GB, max dmabuf count = 32 > > > > etc... > > > > Then, if the dmabuf count encoding space is exhausted, the socket would > > have to wait until the user returns all of the tokens from one of the > > dmabufs and frees the ID (or err out is another option). > > > > This wouldn't change adding a field to the socket, we'd have to add one > > or two more for allocating the dmabuf ID and fetching the dmabuf with > > it. But it does fix the single binding thing. > > I think the bigger problem (than space exhaustion) is that we'd also > have some understanding of permissions. If an application guesses > the binding ID of another app it can mess up its buffers. ENOBUENO.. I was thinking it would be per-socket, effectively: sk->sk_devmem_info.bindings[binding_id_from_token(token)] So sockets could only access those that they have already recv'd on.