From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AA2E33AFD08 for ; Thu, 9 Jul 2026 10:20:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783592423; cv=none; b=jpWEHYa5mcilN81IYVRA2jXwBIHH3tig/jcKTx9sErZzhL3EVw9/U8TEo2wB9dWzjNz5Il2XYa4JIAOmiylqI482I33ubZEZFSb6QAVyrEDLY0MoysE7EEHpb2/m6+1wviOcVflEGVWAoJNgj68YpYUkVvT3Z2ZUOFtkxU56ehY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783592423; c=relaxed/simple; bh=Fyu8emxlCFwSj2y1ERe/C9cL8fe32ZPAE5s01mYBtKE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=tNaOynROn1zTetLLxJZ9L4eav3Zby6x1LSslpr6AUf7D3hgDuH6+RY8WKEkZ9i4MhLkhaDHwMTX2Z4tdqjgOOss/Hft0fXpfoZaxRvktBg6J2F3fiSUHVHiPw6LIeVwhRdEk2yL1jESXUTnDt4xYbg+VYxZJju68VJ0lfl8NhpQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=TkQYk0bI; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="TkQYk0bI" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CB6601F000E9; Thu, 9 Jul 2026 10:20:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783592422; bh=MPfLC5orl3FOJPqKVHrYgEfUBkfZk4Q5lRT44NLSQO0=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=TkQYk0bInxmgbiOA9FOncoBSAGMtj+4O2aDKrMF3sQkk3lVKYVEYVWLhlNCjtHH/h 0ac62rG5qNjPNGJwnjcTdsKTGqi4OpqLkl6A/iDY9RizgvLAYJPynjqSi5WCRYWTbi k70BVKmx6p/gDfx6KuujGDUVuXmBzvn7EIxkI0HLhz3I2PXQXBg+r8M54lv6YCtIoD FPdOhbaji0PqzQ4epn0oXwWIQ54ZVK4X56kVXJo91FnPlUMapy5N25Dv4joagEqqT6 0WcjEKp65OaXqodIL9MCOihLA32LdiYInZWcs2wFVBM9VlerpcHJfpcNNAFWQWE3In krq8LtfPyD96w== From: Pratyush Yadav To: Pasha Tatashin Cc: Tarun Sahu , Pratyush Yadav , Andrew Morton , linux-mm@kvack.org, Mike Rapoport , Alexander Graf , skhawaja@google.com, kexec@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v6 3/3] luo: Update serialized data to use KHOSER_PTR In-Reply-To: <178271651966.13502.2620034351625890943.b4-review@b4> (Pasha Tatashin's message of "Mon, 29 Jun 2026 07:01:59 +0000") References: <20260628001114.1869564-1-tarunsahu@google.com> <20260628001114.1869564-4-tarunsahu@google.com> <178271651966.13502.2620034351625890943.b4-review@b4> Date: Thu, 09 Jul 2026 12:20:19 +0200 Message-ID: <2vxzldbklb18.fsf@kernel.org> User-Agent: Gnus/5.13 (Gnus v5.13) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain Hi Pasha, On Mon, Jun 29 2026, Pasha Tatashin wrote: > On Sun, 28 Jun 2026 00:11:14 +0000, Tarun Sahu wrote: >> diff --git a/include/linux/kho/abi/luo.h b/include/linux/kho/abi/luo.h >> index 288076de6d4a..9e78625cfdc1 100644 >> --- a/include/linux/kho/abi/luo.h >> +++ b/include/linux/kho/abi/luo.h >> @@ -89,14 +90,14 @@ struct luo_ser { >> /** >> * struct luo_file_ser - Represents the serialized preserves files. >> * @compatible: File handler compatible string. >> - * @data: Private data >> + * @serialized_data: The serialized KHO pointer for this file > > I am concerned about layring violation here. > > LUO is designed as a generic, opaque transport layer that promises to > preserve 64 bits of raw data. How those 64 bits are interpreted is > entirely up to individual clients. > > While some clients like memfd_luo will use those 64 bits as a physical > address pointing to KHO-preserved structures, other clients may store a > generic token, cookie, index, or non-pointer status. By > changing u64 data to DECLARE_KHOSER_PTR(serialized_data, void *) in > struct luo_file_ser, we force KHO pointer semantics and layout > constraints on all generic LUO files. That makes sense theory, but in practice, no file handler is going to need only 8 bytes for its metadata. It is always going to need more, and to store more information, it needs to store a pointer to that information with the 64 bits it gets. Do you have any examples of something else one might store here? At least looking at the current file handlers merged and in flight, memfd, iommufd, vfio, pci, hugetlb, guest_memfd, all of them store a pointer here. And if everyone is only storing pointers in this field, might as well give them a bit of type safety. > > Clients that need KHO pointer serialization must cast that opaque 64-bit > value to/from a KHOSER_PTR within their own callbacks. > > Also, the field descriptions in struct luo_file_ser are no longer > aligned due to the length of the new variable name, I believe it will > cause warning when making docs. -- Regards, Pratyush Yadav