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 CB88715687D for ; Fri, 24 Jul 2026 16:46:07 +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=1784911569; cv=none; b=eKaEjqXyHf+9SE9u9g6nTLgLK6jy70yHSqyqRpaFwIc6AlKvkBc9uMcDu9zlNMY2HlmhPWpj6aL4dZsYtH3Ny+dTQZ/KXL1e9RYo97RKIubJyb/pPcVRAZeGVDWY6fNzD7Ga3UroV9QyUAdSpy73+Ml/IJA+fZNBnvfEi/q1PwI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784911569; c=relaxed/simple; bh=3uiGOGGQJucR9k/v4PzMhf8VHEfBTizmmrVZcclObxM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=IvhGPewohV1aJE6n+ByNikfwEkvYNDJ4rv44QpTU0GCIB+wcocIvhemE1QWTz6ArcLBcUHPkOmVp4Vk1gmrIbTB6bDimX/KZTsaedkxS1mQL9PW++xxrHdTilEf5qHuBAD9Ij8+SVXvIrxCRXfUhyuqmfNk65E9QKpiPSvoYg2w= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=soleen.com; spf=pass smtp.mailfrom=soleen.com; dkim=pass (2048-bit key) header.d=soleen.com header.i=@soleen.com header.b=Xc9eDVZi; arc=none smtp.client-ip=209.85.219.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=soleen.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=soleen.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=soleen.com header.i=@soleen.com header.b="Xc9eDVZi" Received: by mail-qv1-f52.google.com with SMTP id 6a1803df08f44-8f0e5e36912so5512156d6.2 for ; Fri, 24 Jul 2026 09:46:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen.com; s=google; t=1784911567; x=1785516367; 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=FftrUEk4ZkE1WXNTNenEBP8mAR3bbgckW3kBU/PXrbc=; b=Xc9eDVZi0BVK2URO8tPVOqdoiS621G+Em3rqp1plMl0ViIqIo5tcL1pPQCWOL4xLaN oNPzs9eLsla9NQbH1waYI1LVsdXO2DQRGsmRgm5sKXTeEli3J0bbQjTVXUjGyZPZ/AeU R5T48sAerRAc+NN6Ny2WENIHlSC/feyrkun6WnR6MRbwC2xPfnqDUEa1/NH7zj/jstRt jZwP5TCJ14OqVDxPf8WWdF51HJAF0GmbcxlcO541ePhMSgDxP2FlME2oEx0c+WC/b2/x EBn7OVYoH/KIXbpqEjvxP/EDp6KA3ZvemlVKUTuXdeot91EPCMaRHKbMYJqJUxhzUotW trCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784911567; x=1785516367; 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=FftrUEk4ZkE1WXNTNenEBP8mAR3bbgckW3kBU/PXrbc=; b=nOJLizVQV+/5mQgZEOE4+54TwmX8K8xYsAOrAQA62Za/ZRMDV5sVqqcSdfr8PostKu fDPlo/apU8AWyR8LGezoI4D83hwVF/6O4//enUj0bzL4k9tSUkJ84EoIIUeXivGhOXgP EjcLy6G3TmKbDf6rf+rtqyqGOxcyTUG/wy2mn69Rn48/89GuAUy6zVoNST5VnkhEKT6N TMdJp0+kVLvGrcMNUQ/D5BSMsBPei9JWsOd5GcHt2qPXRbbtVVwVFNyd4keT6JM9G4Ud VQVcJw34Lyg6TEaS/J/FQ5R6LizEzXgj84alJ3oAwzTsF3rCFkA5OS/EaEzt5kP14Rtp sptQ== X-Forwarded-Encrypted: i=1; AHgh+RrXYslCYCfJ1aHoaqrs21s4xwgHgS1p0g+Ln/ei5hbjABUtL7K/eMg7LFsCpnECCFENHHncKQZHrwh4UCI=@vger.kernel.org X-Gm-Message-State: AOJu0Yx5xW5fFkbQW/T0LFG8pDgax/1UGEeAnZtIE3WL46mVxhDSZMJx ia19acjeZUuKz9GmK4WEK9623GtteKpGW/q7hEKza/fKek9+TXfRw44UOimXd/Q5neY= X-Gm-Gg: AR+sD136b5O9a29/Gu8ZDVVz8Oi4GaBJCPJHUPtIiIXhUwLs0RorqBjSNhs3PsNmITE /Q5yR1pe6Rb5Yx2V9iyuV2CCpCXW0Lw0THLT8otZf+YpElqQaeIJhNnD5kDbZ8VFpz5DH/LuCD2 eFBdYKVhanHC+3EOTp3fVEiXOEx2pne9A9BL3kHhoIQbqLAkSIykhGAp+1gveQgyUt8mB/RyV6e gjIq5cIDy8j5DT333D+FmmnsjDImgpFxNtPhSoGtfilelTR/OT14gNIs+nZPYhgCOd3CGs5U3JK SIdKG9AtMpcU9oL4DD4haxwNEDFrT1LuEoHVNeyOHsyOUuOJaNVb9CrHWkyQ5QqC6aFuyLNzI2w ETa65Vnv23mK8KJ64JWEpPe6dh6nVS3g8TSkbTwFXjcqxXwHxhSPWGKAN6llzEKjZ9/6HEcTCSm Dy4LdFStKPtJ38y74waGxJyAwnNwqs71EKcylLZ1Nq X-Received: by 2002:a05:6214:f0c:b0:8cc:de2:3b5d with SMTP id 6a1803df08f44-907ca5734acmr98718436d6.16.1784911566647; Fri, 24 Jul 2026 09:46:06 -0700 (PDT) Received: from plex ([71.181.43.54]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-907e851ec5esm1986286d6.10.2026.07.24.09.46.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Jul 2026 09:46:05 -0700 (PDT) Date: Fri, 24 Jul 2026 16:46:04 +0000 From: Pasha Tatashin To: Pratyush Yadav Cc: Pasha Tatashin , Tarun Sahu , 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 Message-ID: References: <20260628001114.1869564-1-tarunsahu@google.com> <20260628001114.1869564-4-tarunsahu@google.com> <178271651966.13502.2620034351625890943.b4-review@b4> <2vxzldbklb18.fsf@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: <2vxzldbklb18.fsf@kernel.org> On 07-09 12:20, Pratyush Yadav wrote: > 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. Right, and all of those types are private to file-handlers, not to LUO, so my question is: > > And if everyone is only storing pointers in this field, might as well > give them a bit of type safety. How khoser helps void * type? Pasha > > > > > 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