From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f171.google.com (mail-pl1-f171.google.com [209.85.214.171]) (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 EE59C3890F9 for ; Tue, 28 Apr 2026 23:51:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777420305; cv=none; b=LddF1t7+FSU+1IaZfpDvLGibTQ89rh0ecM3s5ZdIhQqghrGg1US64rtM7BHeRyR34Nro/u19I3rFpXdvM9bEZaEMmDfcODvKlBGwxYryHvlOX58vpTNUG0RJ2rDVLGR+kwe+jDp94T/mZaPlJXEgWexL59lXt/Z7YayO2mc+sjw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777420305; c=relaxed/simple; bh=PzrGjnYnqw4935qMxbE++jGJcpzbiv9Qu385mNo68Ew=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=PPrFQAisyB/QqJVt89o+6bhspZb/nLGV9WB5vj2/guM9TeZn+JUWAihL/t7N4GrKw9eoNiX1WA+1L6nF7FjqiWKBfsht2z7xxOaDEJ4TDq5ITcR0OwjN49MTUEL6tNOYb/8lEsQS8RKQgMPkYc8i10Cla085a2Zs4qykOcX3AM0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=veJ52o7X; arc=none smtp.client-ip=209.85.214.171 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=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="veJ52o7X" Received: by mail-pl1-f171.google.com with SMTP id d9443c01a7336-2b2429f98d0so71393785ad.2 for ; Tue, 28 Apr 2026 16:51:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1777420303; x=1778025103; 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=in+mysCXNp4IJcp8wpKV/ePcsC7P4CQwStR4ajhF2Xo=; b=veJ52o7XgBTZD/d4gsn74d/L9Fe/9u1lhdwWWDUdMNRjuwTZ47RO8vJYkF6NaMe6hC 1wp84OTcSepUS5CpdqRar9FfLrAwyyKwJ5CPifdUNZMVjV9yUfgiczorXrhs/DzK9mMS 3DcXfbfDbKp8cnNCJE1tEbMzE1NqlqcNyfPb5puyT9N3d3r4STq1pgPVZxof7wOWgELM hs6ymFWVJJknOKNQ1XD+miCCzH7iozy3IzAeCI/h+89qcgqNmOElz+jdg8+1HNIuOeqz 93cYPHfeQBPhR2P/9gkmu/B63A+ugtPTYnKvAtYJXGEpGqs0U3AZ1ecgRx1j57VdEgBG T13w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777420303; x=1778025103; 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=in+mysCXNp4IJcp8wpKV/ePcsC7P4CQwStR4ajhF2Xo=; b=VcBe0cZrRItyCTEKajsXQyb0mK3vfPDXjJypdmONWSYirwY3TIThaEOMx+gyiuKZdq nBH62b8ChMPvijfiifEulbvjl/f6/4YEzJZpIiDkmLsdEYZ6MO785UjC68ocaJXAz3rj BBQhZMS9Xd/RMna66dBelFtGQZAI/zZP1aX2ZftGjJcPyBgPNn3gZIXaNyXIy5nRXYCu yAyiR5AENxfuXhBHbRJV8eFcIHA6bgxXMcvJL18S9UCs4GJfQfiCF5X4uhaT4CSNrHQN yIwssyYjkfyOUBJQvM0KNzCYgr+RKMsGpHhav0GZ1VeypTCIruMHf3ccUWgnzljAh6yv 4s/Q== X-Forwarded-Encrypted: i=1; AFNElJ+h+dU3pzlr/eVY1TULgZn71d4kfpMFwAALrR36L4h/N6hkL5UzbWnlMg0G93YRfZ8WIaXZoYWL1XDuPhg=@vger.kernel.org X-Gm-Message-State: AOJu0YyBV3yymtO5o54oW36mJ5N0/qe3BaMZtG/6M8tr+JXN9ALaFYfK tob5BUc2J6vv1kvF8t71Lvm6s2eBRI1J/gAP0EBszedykVggeBLvneyJgECdC6abUQ== X-Gm-Gg: AeBDievLiwgcATTvHLf+D3yeFO/jiBPvq6msus9p7skrYyZPRkDzcewXLOfUka4wIlO WqEdwUanH1UaoDsdBHkavkdJjQEK2YqXMSDWuqtm35SOAPVk26tHOTteGVtxIHa/X9stuKT7wYe tc3MK9hUIXCXXFR3kHtFIvtgPwVdqdKthC16KXgy5TXCT5uO7CMKTnIkLEw73PuFgKpzc7K1jV/ gA8Veql6v28pn0Z500InYCJPEwlkdq/Vxm55OKHOItnL4heVbdvBnGHSBPaii9CEBZtJxkMBLqc KoOIGRy1kocK/Fr5w41e4e4lQYPfKhja7usXP97oBTSv7MeA2BASXv4HlTSgPfP6hzYqFnucAAw pBHUgKHyPBuu3hr1suTdW8wAAE2f7HQe3pCRM44jVw1RXo8OGIKLZ3EZ4SfeLEk1WsOX5JnKdsP FDMozsqBJtG01BqoXxCZE0nnTEA5fTct89QEeYaiIZXv82YQ2qAHytiwkzXNCHO2FWE6NOQ5OIZ mmxKQ== X-Received: by 2002:a17:903:a90:b0:2b2:65db:8c5f with SMTP id d9443c01a7336-2b97c4c8995mr46570035ad.27.1777420302688; Tue, 28 Apr 2026 16:51:42 -0700 (PDT) Received: from google.com (76.9.127.34.bc.googleusercontent.com. [34.127.9.76]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2b98859f629sm3480345ad.0.2026.04.28.16.51.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Apr 2026 16:51:41 -0700 (PDT) Date: Tue, 28 Apr 2026 23:51:37 +0000 From: David Matlack To: Vipin Sharma Cc: iommu@lists.linux.dev, kexec@lists.infradead.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-pci@vger.kernel.org, Adithya Jayachandran , Alexander Graf , Alex Williamson , Bjorn Helgaas , Chris Li , David Rientjes , Jacob Pan , Jason Gunthorpe , Joerg Roedel , Jonathan Corbet , Josh Hilke , Leon Romanovsky , Lukas Wunner , Mike Rapoport , Parav Pandit , Pasha Tatashin , Pranjal Shrivastava , Pratyush Yadav , Robin Murphy , Saeed Mahameed , Samiullah Khawaja , Shuah Khan , Will Deacon , William Tu , Yi Liu Subject: Re: [PATCH v4 01/11] PCI: liveupdate: Set up FLB handler for the PCI core Message-ID: References: <20260423212316.3431746-1-dmatlack@google.com> <20260423212316.3431746-2-dmatlack@google.com> <20260428185242.GB3825533.vipinsh@google.com> 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: <20260428185242.GB3825533.vipinsh@google.com> On 2026-04-28 12:45 PM, Vipin Sharma wrote: > On Thu, Apr 23, 2026 at 09:23:05PM +0000, David Matlack wrote: > > + pr_debug("Preserving struct pci_ser with room for %u devices\n", > > + max_nr_devices); > > + > > + ser = kho_alloc_preserve(size); > > + if (IS_ERR(ser)) > > + return PTR_ERR(ser); > > Should there be a similar pr_debug() in case of failure to denote that above > "Preserving ..." message didn't finish, or, maybe just print one > pr_debug() after the error check above? Hm... I guess there could always be more pr_debug()s but I don't want to instrument every error path. I could move it to the success path but I don't see how that makes it any better. > > > +/** > > + * struct pci_dev_ser - Serialized state about a single PCI device. > > + * > > + * @domain: The device's PCI domain number (segment). > > + * @bdf: The device's PCI bus, device, and function number. > > + * @reserved: Reserved (to naturally align struct pci_dev_ser). > > + */ > > +struct pci_dev_ser { > > + u32 domain; > > + u16 bdf; > > + u16 reserved; > > Should this be renamed to 'u8 __padding[2];' instead? This will allow to > just change the array length based on the need (0, 1, 2, 3). Sorry I'm not following what you mean here. What is the reason to rename this field and change it to an array? > > +} __packed; > > + > > +/** > > + * struct pci_ser - PCI Subsystem Live Update State > > + * > > + * This struct tracks state about all devices that are being preserved across > > + * a Live Update for the next kernel. > > + * > > + * @max_nr_devices: The length of the devices[] flexible array. > > + * @nr_devices: The number of devices that were preserved. > > + * @devices: Flexible array of pci_dev_ser structs for each device. > > + */ > > +struct pci_ser { > > + u32 max_nr_devices; > > + u32 nr_devices; > > + struct pci_dev_ser devices[]; > > +} __packed; > > + > > +/* Ensure all elements of devices[] are naturally aligned. */ > > +static_assert(offsetof(struct pci_ser, devices) % sizeof(unsigned long) == 0); > > +static_assert(sizeof(struct pci_dev_ser) % sizeof(unsigned long) == 0); > > Nit: Maybe move this assert to be near to the definition of this struct, > easier to find it when editing the struct vs finding it later during > build. The combination of these 2 asserts is what guarantees that every element of the devices[] array are naturally aligned, that's why I put them together here. I can move it up though if you think it's better.