From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yw1-f178.google.com (mail-yw1-f178.google.com [209.85.128.178]) (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 BD98E335086 for ; Wed, 5 Nov 2025 17:59:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762365576; cv=none; b=Ipzw7pHm1/R54dixUqoJsJ0iW60vJOVHcqew7pbVR53nyDGfoGRy/wcK+R+WQkHU8TIY6klEJl68Q19M/1jCP3Hkr6xrSM07siEKKCRnN9TZQUhRok4ia6noem1QEn5CySCFwMdfZlJU7mktwmohEk7pyRCr8Q8Q9SjGBX6qTvY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762365576; c=relaxed/simple; bh=Nnp1wDC3H73w3jI8NtJcSVR2N83rdAhx/dtATqrWYag=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=fv+wUZCB8DMtkjQApJpGVZvNLKKxjMvzqJVnNc1aGtT7bqtX+15DrKUT67ipoXGuGhrnUVmZiwVNJVoCTBTugHdaq3qhqWeg2WoX2B0rIHZH+kB/b/r/1+b2dSBWOu8CIOF/dy8c5WPqxgXX7AFQnXlQtf4uawy4tiMmfxGyrvU= 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=Wtm5i7Ve; arc=none smtp.client-ip=209.85.128.178 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="Wtm5i7Ve" Received: by mail-yw1-f178.google.com with SMTP id 00721157ae682-786a822e73aso521867b3.3 for ; Wed, 05 Nov 2025 09:59:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1762365574; x=1762970374; 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=zSHtYrMJfyWXNB5+D7qGmo5liVfUAPUmYconSQ05yJA=; b=Wtm5i7Vel6og71cIYNi68wga2ylq1eSG/Yhr/KPEnj+sHZCTbCPH/BDgN+LYIacV8L skAnPmPwk4Eq8LfFcNj/KAz3bxnQfryS83ZS8mxM/pRUehxODb3wQhjs1uRRVXtKD9e3 8UNcK6mT7yf7agUTYTdUEWqrnLhOFsqKzwcsp01gtWEWpk5T3qEUz6nxByKQ0DJkpwK2 d+LL5dDSB8eSgK36DMExPxtwDq2/GiG2e+8hNze0WH3Iats5Xv8ipySifO952J1Uf0Fm +EpbAKeOuGqhSpdNO9E7cZf1Pp7ocaGLOZzN4N6pu8letXaCjkrOYHWc/4egXZ00I1NQ nabQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762365574; x=1762970374; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=zSHtYrMJfyWXNB5+D7qGmo5liVfUAPUmYconSQ05yJA=; b=NLQPRw9fW39B7XxxmHCih8yQZyPql6zDRi4GCWHhKjm10u5DfEOS+YeYDoo5hAxeux mInmhbtqIiMiXdw8qgSL6Wkm+6+52RjVTiUzCriPjznXcUdlii6Ap/9z/wTJBwuUwI3D tjQL102PonBp+fx+crtCAHwcaVcfHEs4K8WE8cJgLpnCalGmLy8aNc04RIPKTlIddKcb 1syZlIOzJKvoR22fnYaSP5XSjBk80BXXoIZlJJ9BkQhJlkz0AyyiOcLblSaisNau7uo5 e0zgUmD3tVJR5VsO4eAVpCIu4vghceNJDIrmKU7r2YK0GJ4hEsBfGja9Np6iFz7CacLa QwmQ== X-Forwarded-Encrypted: i=1; AJvYcCWsvcbNAKq4cPZuQ+TQ9NODLj4eEhW/ypBPYkzT9sIzFDvtl9PKCTCXBOrKoU2UReRAJ2nYHL9w3EXOpifli6I=@vger.kernel.org X-Gm-Message-State: AOJu0YweTrunY+1MRwqnBvKCfUVPY6srCkBGwA7OYRzdcTZq17eAnoeq b0nCN8iull/koUrirw6jhfwbef1HWXuRtaBfS7JVRaB8t+9ilIfx8KTu X-Gm-Gg: ASbGncuCjIXhQ+cgFzNp3rFUrpefBM6YvRL52sXa1eUhYvtJXC8Bdc3EOH92rY67nxc jv1S57Ci4L50JcukFmiQ/7J5WoEcwBdX5jOEsrI0KQMrzOMHS30fAvgPTsre1rYWibfupMXbxEC 7o5bt3VjS6Te4C5OOciNrDlMBzJKgp8DM2BaQHYFHxtg1/uY/X4AjzDzEz+wF9js76lB9css2nu rcJptZ1sN9hd0VwN3ec+MF9s8qxEvTHrqSU/VoxYGGeh1dKdkm3eTOpn6uwsJDZJziSO8dW+/ZR 2TzlK5ft42/Y8j/Me92fX42VOzeJLJEuJzZ2OuhMa1J7/x3mwcpQ0wKMsOMTz7LadgITs/uktAk Gv4WraCFyIa2/Rgu7zprMBcu4MiJHn3AHCNvQNM8RdtByB/mksH8+p5mdBMQRXU1eMn4OUoK0qX tIReC2Xut26dmyE8nZoVpp02ZkYod0+NIwT3ds X-Google-Smtp-Source: AGHT+IHHyTsN8YO880iJh6XJa9T07Q+L4vBMRDgiJVACQ1JdCPPRDqaW0LijeD633oiPcNo5B7xioA== X-Received: by 2002:a05:690c:fc2:b0:787:1aba:3081 with SMTP id 00721157ae682-7871aba3718mr18241127b3.58.1762365573471; Wed, 05 Nov 2025 09:59:33 -0800 (PST) Received: from devvm11784.nha0.facebook.com ([2a03:2880:25ff:59::]) by smtp.gmail.com with ESMTPSA id 00721157ae682-787b13b6954sm735637b3.5.2025.11.05.09.59.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Nov 2025 09:59:32 -0800 (PST) Date: Wed, 5 Nov 2025 09:59:31 -0800 From: Bobby Eshleman To: Stanislav Fomichev Cc: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Kuniyuki Iwashima , Willem de Bruijn , Neal Cardwell , David Ahern , Arnd Bergmann , Jonathan Corbet , Andrew Lunn , Shuah Khan , Mina Almasry , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org, Stanislav Fomichev , Bobby Eshleman Subject: Re: [PATCH net-next v6 5/6] net: devmem: document SO_DEVMEM_AUTORELEASE socket option Message-ID: References: <20251104-scratch-bobbyeshleman-devmem-tcp-token-upstream-v6-0-ea98cf4d40b3@meta.com> <20251104-scratch-bobbyeshleman-devmem-tcp-token-upstream-v6-5-ea98cf4d40b3@meta.com> Precedence: bulk X-Mailing-List: linux-kselftest@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 Wed, Nov 05, 2025 at 09:34:03AM -0800, Stanislav Fomichev wrote: > On 11/04, Bobby Eshleman wrote: > > From: Bobby Eshleman > > > > [..] > > > +Autorelease Control > > +~~~~~~~~~~~~~~~~~~~ > > Have you considered an option to have this flag on the dmabuf binding > itself? This will let us keep everything in ynl and not add a new socket > option. I think also semantically, this is a property of the binding > and not the socket? (not sure what's gonna happen if we have > autorelease=on and autorelease=off sockets receiving to the same > dmabuf) This was our initial instinct too and was the implementation in the prior version, but we opted for a socket-based property because it simplifies backwards compatibility with multi-binding steering rules. In this case, where bindings may have different autorelease settings, the recv path would need to error out once any binding with different autorelease value was detected, because the dont_need path doesn't have any context to know if any specific token is part of the socket's xarray (autorelease=on) or part of the binding->vec (autorelease=off). At the socket level we can just prevent the mode switch by counting outstanding references... to do this at the binding level, I think we have to revert back to the ethtool approach we experimented with earlier (trying to resolve steering rules to queues, and then check their binding->autorelease values and make sure they are consistent). This should work out off the box for mixed-modes, given then outstanding ref rule. Probably should add a test for specifically that... Best, Bobby