From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=209.85.208.71 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793634736; b=G7juDQ52523/lMNMpofURRgssNOAVlQKRNloO+kJ2siGqu9Asw8mef+OgQnIwMnd54nn PXyqkXpZWNOwv//3cjrTOvliCaoLdnr3jEqeTdB58W1HbpbtkYNWVAJub0X/0GuhV+6TM NHHCVJwTS2rFjLeyvGgp9O5Dua3A8KwCFHSB+Sm03J2QsG/NOt4+yGbbZQs/K4jPCxCzR 9jIPNTnWKOUuLkRV6TwfykrqLJvHrWln051cFDy6bsnfwwyJ7rHpiODN4K009mAn4S5+7 NwZ/EOLxHfT4zQQ7VHubMjRknNVCqUKp4TFwuvCuickDSvDVVtHUGE9tai7pw4x2xxg== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793634736; h=DMARC-Filter:Received:DKIM-Signature:X-Google-DKIM-Signature: X-Forwarded-Encrypted:X-Gm-Message-State:X-Received:Date:In-Reply-To: Mime-Version:References:Message-ID:Subject:From:To:Cc:Content-Type: Content-Transfer-Encoding; bh=j6RtsTbIlQ1+MerKC0xhFDG/d459vnICRyJwyVtriLE=; b=LQuvq33UIQxMzL/HYW+SChXu3aeQVaH7eIlNdF2JZ2cWc1U/g1RlY1ruU1+Z+2nmZkZ+ bftCuyhuEg9tgGBNoeiQ/6p89gCATy/4durOInBq6cETTAa/Guc7ctpn8aDHj/Bqe9G9E GYuk8Uhoe+FOQzWmZP3lTGJOz1d2IPq7at7tWZ7jNp4Ia4ifQgJMY27DeZ2QrT3LBXP6L S1wwoLNj5loadB6MuADhB/soOImGAnPkC2XSSBtNzaThKypELQ0XRYe4d6jzAH//LMJoh op4p7r3A5rlIRLQYDNzmMSWgcowxrr127D58Tp/wPnrgiGJIIJoh5mASwsNKc7xvtig== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=google.com; spf=pass smtp.mailfrom=flex--tarunsahu.bounces.google.com; arc=none smtp.remote-ip=209.85.208.71 Received: from mail-ed1-f71.google.com (mail-ed1-f71.google.com [209.85.208.71]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AF32F607827D for ; Mon, 2 Nov 2026 15:52:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org AF32F607827D Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--tarunsahu.bounces.google.com Received: by mail-ed1-f71.google.com with SMTP id 4fb4d7f45d1cf-6b1d818b501so1330751a12.0 for ; Mon, 02 Nov 2026 07:52:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20260707; t=1793634734; x=1794239534; darn=vger.kernel.org; h=content-transfer-encoding:content-type:cc:to:from:subject :message-id:references:mime-version:in-reply-to:date:from:to:cc :subject:date:message-id:reply-to:content-type; bh=j6RtsTbIlQ1+MerKC0xhFDG/d459vnICRyJwyVtriLE=; b=BHPvzdIUTfLewJrYkQH7AM5ACZXWMySrmwNdCiSs5e6SI86mj4u2FQFZ7r+Sb1n78o gc7efW8JFDUlvS0IFhI4lySJQ+geqabqJd3Q5I7XQAl3Y3/Yw/+TdJ8ntmwzO5rfOTpG PoKQ8nTXisY9CAUjnrWbqf8y6JSz5U9KT5YbVXJcpFQQX4bZ54DVJBvod155mno//Klr K4qF7GT6YqPFEocNq77QalEX6VfNP+5OPCh9Rl51yPooTkxLTI41oszKeo9V3be0MCxE 125q2mUMZMjjNDHFbTMTsuMzt+8SAccC+vqPIehEIlLY04xwwd9hOUGvIAqgUWFvNJVv m9GQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793634734; x=1794239534; h=content-transfer-encoding:content-type:cc:to:from:subject :message-id:references:mime-version:in-reply-to:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=j6RtsTbIlQ1+MerKC0xhFDG/d459vnICRyJwyVtriLE=; b=cF7PaEbAHf6uSZCyci6bDRMHm7ifBrD9uRPoJn4NSaSvtOiHKF2iVV0RskLBqNvjxm dD4YM1RFd+Q9pSHtLIDYPLmIiV8ZheZrcpIcSg8mKrF7BHs59Q8PkQD9JSDxi4wqK+Dy iGmSEBLWk6IzbmPlSPY7bZOSB//SwpRgOmQvx5XvP9+ezPyy1+eCIJclhg5sjXHRgade 97i7xjW6FCDw7GmHv/VRiQfOoXY79SmUFf22d9X6uSg61qYxHOmA3VqEuEfXqxmPv5U5 o/xkKMH4vMmDgXKHD8myFA/5qpGjwph7DndgvWkWBoIwTUNkOlMQKL7qqaGokTjUApjV 14lA== X-Forwarded-Encrypted: i=1; AKwUvBxCyMckdeAgxXtsJJMs9FjOoQfglgJXtsPJ3hD/3DboxqBybD+/LTUEL8JP6mr2qMMaQCsPpyes/T1jKHo=@vger.kernel.org X-Gm-Message-State: APuU4Z80xdNg8AOlCTWhb4VuUxRkaEtXNrFsxV9+Jmty4XI1yPRnFNdP nBm507krW9ILmfMhZ4vyJ+aBIU4Qd4fLpuB0GYEKN3PP2NggdXX+o5pFFquhuheonw8cFjbph3B OAgFGjwtQLRbT8CZvUA== X-Received: from edwr13.prod.google.com ([2002:a05:6402:34d:b0:6ac:bd6a:1c30]) (user=tarunsahu job=prod-delivery.src-stubby-dispatcher) by 2002:aa7:cc09:0:b0:6ac:7737:e50d with SMTP id 4fb4d7f45d1cf-6b4d4d83eb2mr5865537a12.29.1793634733847; Mon, 02 Nov 2026 07:52:13 -0800 (PST) Date: Mon, 02 Nov 2026 15:52:12 +0000 In-Reply-To: X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list Mime-Version: 1.0 References: <2vxz8q3hoicx.fsf@kernel.org> Message-ID: <9huzik2fz0wj.fsf@tarunix.c.googlers.com> Subject: Re: [RFC PATCH v2 3/4] liveupdate: Replace compatibility string with a 2-bit pair feature header From: tarunsahu@google.com To: Pasha Tatashin , David Matlack Cc: Pratyush Yadav , Pasha Tatashin , Andrew Morton , joro@8bytes.org, Mike Rapoport , maz@kernel.org, arnd@arndb.de, jgg@nvidia.com, robin.murphy@arm.com, loganodell@google.com, oupton@kernel.org, kevin.tian@intel.com, alex@shazbot.org, dwmw2@infradead.org, pbonzini@redhat.com, seanjc@google.com, will@kernel.org, Alexander Graf , Bjorn Helgaas , baolu.lu@linux.intel.com, linux-arm-kernel@lists.infradead.org, linux-arch@vger.kernel.org, sagis@google.com, linux-mm@kvack.org, kvmarm@lists.linux.dev, iommu@lists.linux.dev, linux-pci@vger.kernel.org, kexec@lists.infradead.org, skhawaja@google.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Pasha Tatashin writes: > On 10-28 10:24, David Matlack wrote: >> On Wed, Oct 28, 2026 at 10:17=E2=80=AFAM Pratyush Yadav wrote: >> > >> > On Mon, Oct 26 2026, David Matlack wrote: >> > >> > > On 2026-10-25 04:38 PM, Pasha Tatashin wrote: >> > >> On Fri, Oct 23, 2026 at 9:50=E2=80=AFAM David Matlack wrote: >> > > >> > [...] >> > >> The reason I care about keeping the header compact is that we are >> > >> defining a foundational kernel ABI and want to use this header acro= ss >> > >> almost every serialized data structure so we can evolve them later >> > >> without breaking compatibility. While some top-level structs are on >> > >> sparse folios today, other serialized structs are tightly packed, a= nd >> > >> we are looking to add KHO slab support in the future where tightly >> > >> packed allocations will be common. >> > > >> > > My intuition is we will have a small number of headers per preserved >> > > file and per preserved FLB. One for the top-level struct and then >> > > optionally a few more for sub-structs like arch-specific data. That = is >> > > why I am less worried 8 bytes per header, even if we fix the folio >> > > problem. >> > > >> > > Maybe where our visions differ is when there are collections of >> > > serialized structs, like KHO blocks. For collections I don't think t= he >> > > elements will each have their own headers. Otherwise the elements co= uld >> > > be different sizes. >> > >> > kho_block today doesn't store entry_size in the serialized payload. It >> > relies on its caller to do so. With extensible structures, this can ge= t >> > messy. Sure, the owner of the kho_block_set can track the size somewhe= re >> > in its payload, but perhaps we should store the size in >> > kho_block_header_ser to begin with? >>=20 >> +1000 >>=20 >> KHO block should track the entry size automatically and not rely on >> the caller. Otherwise every caller is going to have to store the entry >> size in the struct that owns the KHO block, like I had to do in the >> PCI v10 series :( > > I am fine with updating this as part of the versioning change so that we= =20 > do not have to do it twice. > > Tarun, could you pelase include entry size change into the next version a= s=20 > well? Yes, This will be important to track the extensible serialized structure across kernel. For example struct luo_session_ser has larger size in N+1 kernel which gets deserialized on the beginning of the boot so incoming block_set must use entry_size of the kernel N which we can update inside kho_block_set_restore(). And this updated incoming->block_set be used for iterator in luo_session_deserialize to properly walk through session_ser entries. I will send v4 soon including this. ~Tarun > > Thanks, > Pasha > >>=20 >> > Anyway, not a problem this series needs to solve, but something we >> > should eventually do.