From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail-pf1-f201.google.com (mail-pf1-f201.google.com [209.85.210.201])
	(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 6D2AD3A0B36
	for <linux-kernel@vger.kernel.org>; Thu, 28 May 2026 17:41:48 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.201
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1779990109; cv=none; b=slS3w26TY9wBZCsvN7e9jkzLQytnPxjuqDQR/gv6UWl4vrb0I/rAxfMm7hM6KHNlFsKiCNo3/Hhc2n72BXm9lEn+EncXYW5dOJBBDqaNsiqJFGW7hYH7lRlnJNMUWNNV38b7DTLPTXajH5Se0VuYMBx8syrH9DRykvme/88ADk4=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1779990109; c=relaxed/simple;
	bh=IUQ7pcn/kwD5kmSsG7LBNLPxSTAvHPFBLQXfcGoHTDU=;
	h=Date:Mime-Version:Message-ID:Subject:From:To:Cc:Content-Type; b=oA1cIM2YBcPDU9zayyStINfMRqbprrCJkDnAghUuI8CfO86QkixiKpH4HB3I4RRrnTbZ5TWDE3XgQtRaZwmiZpm9BlE6oXM6dDjdG4XudAnsLjJ/Px7Ue6Vqw2jl1lwLTdjzCyn72M8qM2npMd93bT4qclwOJQZ7DgSyVbsixsU=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--dmatlack.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=s7UQKZk7; arc=none smtp.client-ip=209.85.210.201
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--dmatlack.bounces.google.com
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="s7UQKZk7"
Received: by mail-pf1-f201.google.com with SMTP id d2e1a72fcca58-83cecc22d5fso6995583b3a.2
        for <linux-kernel@vger.kernel.org>; Thu, 28 May 2026 10:41:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1779990108; x=1780594908; darn=vger.kernel.org;
        h=cc:to:from:subject:message-id:mime-version:date:from:to:cc:subject
         :date:message-id:reply-to;
        bh=2tns20Jc2qFQBaO3MIIRuCNGNOwNtzQn34pDKtjl1l8=;
        b=s7UQKZk7ayzrrhesbUgR2xwTXjRDI3kCmV+ksD+bmMndLDcTZuj+Pk2Cxmqsg1ZwR5
         mF22D1DPjJ3xEbBntE8gh06C0Tdf0upMiH1g9cNcdpq7QgcjjSi6H1KbuAZr9gsrIgxI
         EZr8MnbpdwwcgUD6LjspXsrkyDPnVk2KlJmAnNXExDtwTwjVykRXfPkJXEw8AjM0al8g
         IPpJ15bZCSFKOA4L6rZnGHOX/5DVYw8MM252esWF+JlqyHFePHB4666WNE3vEaTeQQc2
         wdcF1S5MU0xzphWPFR0M0r3R7BqVRuhBtmbyQS95PoihLAATUbI6o0MekipwGzcb0LGh
         4gBg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1779990108; x=1780594908;
        h=cc:to:from:subject:message-id:mime-version:date:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=2tns20Jc2qFQBaO3MIIRuCNGNOwNtzQn34pDKtjl1l8=;
        b=HDWmWt3s7Lrfs6vu2kve7KVIfmYHkJa/uTF1o1Tes2v8AT7f93k+jcEKM5OmBM2rDx
         3H3wuU+m5/NNFPQ1hpDx3z0B6UFIYmGKBEnwabbw9+qs7B4E03wbQt8GzZwBMyh+mGS/
         jbKrbkxtd5GOQyrQKXNCyCkw4QpMGZh3rsTeQigY9DmKQEJ7Gd4mJEaaL2o+lKvI97hp
         PQdnB16aYUwD0wYtO0zw8RqdfVZq9e1OAtn5q69sIcgYgZsi/OAk4H1+1h58afEY3e6+
         9LoW6HEwKJTDl+ZxMP2Z2awM3a8xCz8vSoyYF642ccD5GBmPwgiE5pYC3y3IhpiA8Ruv
         7zVQ==
X-Forwarded-Encrypted: i=1; AFNElJ9NuIv4y0JsWNiwlfOY0l/1i8CUp00kXLotNTSkkyJJNNGAKVmmIdDsjN8UyzMiggkLIKHW6yGcuAPxPDs=@vger.kernel.org
X-Gm-Message-State: AOJu0Ywf0hxoGp0KduwOY+KuLWzH0ToSS5PVFNFMrNOyXAT1Qplv/W24
	9MRJ67SHQRedIekXt7hMd/L+TN/kXW8W6zcOofHP0Z6+KfRZKjnqEPam0hxp3DOBaFqqS36kpXy
	cEsS29nyvcAL01w==
X-Received: from pfbmc49.prod.google.com ([2002:a05:6a00:76b1:b0:82f:a959:4a7f])
 (user=dmatlack job=prod-delivery.src-stubby-dispatcher) by
 2002:a05:6a00:1412:b0:81e:ef16:b288 with SMTP id d2e1a72fcca58-8415f37d836mr28903501b3a.22.1779990107456;
 Thu, 28 May 2026 10:41:47 -0700 (PDT)
Date: Thu, 28 May 2026 17:41:38 +0000
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
Mime-Version: 1.0
X-Mailer: git-send-email 2.54.0.823.g6e5bcc1fc9-goog
Message-ID: <20260528174140.1921129-1-dmatlack@google.com>
Subject: [PATCH 0/2] liveupdate: Small FLB fixes
From: David Matlack <dmatlack@google.com>
To: kexec@lists.infradead.org, linux-kernel@vger.kernel.org
Cc: Andrew Morton <akpm@linux-foundation.org>, Mike Rapoport <rppt@kernel.org>, 
	Pasha Tatashin <pasha.tatashin@soleen.com>, Pratyush Yadav <pratyush@kernel.org>, 
	David Matlack <dmatlack@google.com>
Content-Type: text/plain; charset="UTF-8"

This series has 2 small fixes to how FLBs are managed. First is to
increase the outgoing FLB refcount during liveupdate_flb_get_outgoing()
so it cannot be freed while the caller is using it, and to align with
the semantics of liveupdate_flb_get_incoming(). The second is to prevent
FLB retrieve() from being called multiple times if the first attempt
fails.

Both of these changes are needed for the correctness of the PCI core
support for Live Update:

  https://lore.kernel.org/linux-pci/20260522202410.3104264-1-dmatlack@google.com/


David Matlack (2):
  liveupdate: Reference count outgoing FLB data
  liveupdate: Remember FLB retrieve() status

 include/linux/liveupdate.h  | 11 +++++++++--
 kernel/liveupdate/luo_flb.c | 20 ++++++++++++++------
 2 files changed, 23 insertions(+), 8 deletions(-)


base-commit: 5428435567cbe06c19914592fc22ca23c9ca1de5
-- 
2.54.0.823.g6e5bcc1fc9-goog


From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail-pj1-f74.google.com (mail-pj1-f74.google.com [209.85.216.74])
	(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 2C8F73AC0D7
	for <linux-kernel@vger.kernel.org>; Thu, 28 May 2026 17:41:49 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.74
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1779990110; cv=none; b=bWFCduqeLwEj0gHjlr0neRfZeOyhOC9dXPPleBcle7x6osi3kyNiITb3TzPMouVgcS6w8gwuJ8R3z1n0I1wBh8QHBvZK82wiAq3R73GNvYmeuEK1sQAoKZwa0ZJ0xo0kL/YDX139rU52WZWzIm8Hjsx0JK/aPsTdKVlAwI1uHvE=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1779990110; c=relaxed/simple;
	bh=QBhXuBBdQPBnfjmLP7bmvCQIK0Vud7gW3z0f/PHyerg=;
	h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From:
	 To:Cc:Content-Type; b=REtS2HbrWj3FCtE+VFxeiHT5fGi6Ob8OVKAl3TljCDY2G7W6XivVRyjoSj8NJzMwmOW8nhqHU2fl73Q55a0X6LYbOZwcMp/RwVhuOA2U8so2Y0X75S/UsXMCkYDuWzhRbIvtaBDWMcD9FUTPsrNO+U9TEzufsWXpe3axifltJg0=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--dmatlack.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=QcXfirr+; arc=none smtp.client-ip=209.85.216.74
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--dmatlack.bounces.google.com
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="QcXfirr+"
Received: by mail-pj1-f74.google.com with SMTP id 98e67ed59e1d1-365ff2ab7beso13783474a91.1
        for <linux-kernel@vger.kernel.org>; Thu, 28 May 2026 10:41:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1779990108; x=1780594908; darn=vger.kernel.org;
        h=cc:to:from:subject:message-id:references:mime-version:in-reply-to
         :date:from:to:cc:subject:date:message-id:reply-to;
        bh=0poEg6dzE32DnYuKI7VywdtZZms3dhY1RszrIEICmMM=;
        b=QcXfirr+U2LcHT+TBmwiLlCM/AhyK9Tqq2+HdhtbmMZL6fCBwyvqIzI2JJYd3RgITk
         dPuD1q+rSbSDlM37JzWhQXApP8YMrFK13GH1cCVb8AQoYzkKeTh7Awdw5aUYAJhr7vcD
         cLw2H6MhHp5lFarj4KCbVRQfNhdvLrX72CL0VJbp/kyRvm1qLgb9OK/27GDgK/oRFcdW
         Rt52gxocTGabmgvQ4s45oWJDAywVj5a44Lj65jbTVBk6BI5NI9ho2pocrLl1I+YLjd/T
         GVnNSgugdiY4bECOCupKQgtymlOhV3mWDbSm1o1uWosKjt4bAFtjUNRd7HmMSCvhk6a6
         lUsw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1779990108; x=1780594908;
        h=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;
        bh=0poEg6dzE32DnYuKI7VywdtZZms3dhY1RszrIEICmMM=;
        b=tHmKysJyYQ//JcIh4STohGD/eAduy9CZbqtBArVAwRGfA99YgZtDZi1iIxilXTPjkm
         XIFPiLV+mf73EI+ib5tK5dNupuYvXqWZlfDW2a6+9OKrTi77pwShsGK++KIkI3G58SP+
         RSc4OtaubyGmRngN2qo1Oh9mlZLPLtLVk6Zq25SsNEjY6D1R1Uvzs8Tcocb9l8Om++Tf
         thU+83I23muMXUL6kEJy0RCVlbqPahNHNshF+5NAgQmOYXGHKShDCVY/H8pTSc3Lzejg
         gEwpb0Bh9vCB9fuZuj6rQz2licWi0CyDa2VcdvZMyzY4npxRC501yB8/WL5A+OOrb/9W
         QNtA==
X-Forwarded-Encrypted: i=1; AFNElJ+YHmyF0c5FcOpy5XWg84xubm3AG3XlV7GFCc/Nomffw1gH+OWOaTUQby9cPrGpA7Oui20sI3bsVzKD9yI=@vger.kernel.org
X-Gm-Message-State: AOJu0Yw5MqCBDLLOOwElJ4vA7Ne3FvxFFhtHya8D388nEC0KE3H4ljp7
	Ok3vaXy3dYixiBIgcagCUteCSr34951iMCY7YKvnGs+iUZcJUtqNtupq2+8Qiwn8bxMMDC1KFjX
	+rr7t9VH2t9+wog==
X-Received: from pjbei7.prod.google.com ([2002:a17:90a:e547:b0:36a:7f0b:e285])
 (user=dmatlack job=prod-delivery.src-stubby-dispatcher) by
 2002:a17:90b:544b:b0:36b:9798:4f68 with SMTP id 98e67ed59e1d1-36b9c9717d1mr2611746a91.9.1779990108327;
 Thu, 28 May 2026 10:41:48 -0700 (PDT)
Date: Thu, 28 May 2026 17:41:39 +0000
In-Reply-To: <20260528174140.1921129-1-dmatlack@google.com>
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
Mime-Version: 1.0
References: <20260528174140.1921129-1-dmatlack@google.com>
X-Mailer: git-send-email 2.54.0.823.g6e5bcc1fc9-goog
Message-ID: <20260528174140.1921129-2-dmatlack@google.com>
Subject: [PATCH 1/2] liveupdate: Reference count outgoing FLB data
From: David Matlack <dmatlack@google.com>
To: kexec@lists.infradead.org, linux-kernel@vger.kernel.org
Cc: Andrew Morton <akpm@linux-foundation.org>, Mike Rapoport <rppt@kernel.org>, 
	Pasha Tatashin <pasha.tatashin@soleen.com>, Pratyush Yadav <pratyush@kernel.org>, 
	David Matlack <dmatlack@google.com>
Content-Type: text/plain; charset="UTF-8"

Increment the outgoing FLB refcount in liveupdate_flb_get_outgoing() so
that the FLB structure cannot be freed while the caller is actively
using it. Add an additional liveupdate_flb_put_outgoing() function so
the caller can explicitly indicate when it is done using the outgoing
FLB.

During a Live Update, the kernel may need to fetch the outgoing FLB
outside of the scope of a file handler's preserve() and unpreserve()
callbacks. In that situation there is no way for the caller to protect
itself against the outgoing FLB from being freed while it is using it.
Incrementing the reference count in liveupdate_flb_get_outgoing()
ensures it cannot be freed.

This change also aligns the outgoing FLB lifecycle management with the
incoming FLB, since the latter uses the same get/put semantics.

Fixes: cab056f2aae7 ("liveupdate: luo_flb: introduce File-Lifecycle-Bound global state")
Assisted-by: Gemini:gemini-3-pro-preview
Signed-off-by: David Matlack <dmatlack@google.com>
---
 include/linux/liveupdate.h  |  5 +++++
 kernel/liveupdate/luo_flb.c | 10 +++++++---
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/include/linux/liveupdate.h b/include/linux/liveupdate.h
index 88722e5caf02..c344bf987b63 100644
--- a/include/linux/liveupdate.h
+++ b/include/linux/liveupdate.h
@@ -243,6 +243,7 @@ int liveupdate_flb_get_incoming(struct liveupdate_flb *flb, void **objp);
 void liveupdate_flb_put_incoming(struct liveupdate_flb *flb);
 
 int liveupdate_flb_get_outgoing(struct liveupdate_flb *flb, void **objp);
+void liveupdate_flb_put_outgoing(struct liveupdate_flb *flb);
 
 #else /* CONFIG_LIVEUPDATE */
 
@@ -292,5 +293,9 @@ static inline int liveupdate_flb_get_outgoing(struct liveupdate_flb *flb,
 	return -EOPNOTSUPP;
 }
 
+static inline void liveupdate_flb_put_outgoing(struct liveupdate_flb *flb)
+{
+}
+
 #endif /* CONFIG_LIVEUPDATE */
 #endif /* _LINUX_LIVEUPDATE_H */
diff --git a/kernel/liveupdate/luo_flb.c b/kernel/liveupdate/luo_flb.c
index 8f5c5dd01cd0..7ddef552ff6b 100644
--- a/kernel/liveupdate/luo_flb.c
+++ b/kernel/liveupdate/luo_flb.c
@@ -135,7 +135,7 @@ static int luo_flb_file_preserve_one(struct liveupdate_flb *flb)
 	return 0;
 }
 
-static void luo_flb_file_unpreserve_one(struct liveupdate_flb *flb)
+void liveupdate_flb_put_outgoing(struct liveupdate_flb *flb)
 {
 	struct luo_flb_private *private = luo_flb_get_private(flb);
 
@@ -266,7 +266,7 @@ int luo_flb_file_preserve(struct liveupdate_file_handler *fh)
 
 exit_err:
 	list_for_each_entry_continue_reverse(iter, flb_list, list)
-		luo_flb_file_unpreserve_one(iter->flb);
+		liveupdate_flb_put_outgoing(iter->flb);
 	up_read(&luo_register_rwlock);
 
 	return err;
@@ -291,7 +291,7 @@ void luo_flb_file_unpreserve(struct liveupdate_file_handler *fh)
 
 	guard(rwsem_read)(&luo_register_rwlock);
 	list_for_each_entry_reverse(iter, flb_list, list)
-		luo_flb_file_unpreserve_one(iter->flb);
+		liveupdate_flb_put_outgoing(iter->flb);
 }
 
 /**
@@ -546,6 +546,10 @@ int liveupdate_flb_get_outgoing(struct liveupdate_flb *flb, void **objp)
 		return -EOPNOTSUPP;
 
 	guard(mutex)(&private->outgoing.lock);
+	if (!private->outgoing.obj)
+		return -ENOENT;
+
+	refcount_inc(&private->outgoing.count);
 	*objp = private->outgoing.obj;
 
 	return 0;
-- 
2.54.0.823.g6e5bcc1fc9-goog


From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail-pg1-f202.google.com (mail-pg1-f202.google.com [209.85.215.202])
	(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 0399D3F8EB5
	for <linux-kernel@vger.kernel.org>; Thu, 28 May 2026 17:41:49 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.202
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1779990111; cv=none; b=gbXUwdQLhqIxe5mLClTSoJpWXrDrs36GBvggwuZSHwLgNJ9WsSVswdefDdZUUdDtWDM/XNUFV6h3fLq6CfoLvhVPdOGmknnEY70gNAQcyqixaVTQp9PZvA8734OjtPFLBZiNC5tv//CABRiReTnRmx1805JXRLNRHb4XmELSJZI=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1779990111; c=relaxed/simple;
	bh=KAMdx8s2C1zMEwaN5gNaaXfmuRTW1H6Sy6SYcyTzxI4=;
	h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From:
	 To:Cc:Content-Type; b=rVmuDwqogPyc3FQTO7SJ62xYAebqix2V9eQ/xyiOP70JpEPPpNf7vYos6Li3aq1JGfZ3eBVW6KJWMYGLZ3YIWiR5c3Vp7mM2sVp6gyCkjjdA6qDDJaYJ6NlUIiCwY8c4JynYUaWUAEar/UcSsq8VBuLk+0D2L0I9tJw7kU923qY=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--dmatlack.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=ZeOzaDSq; arc=none smtp.client-ip=209.85.215.202
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--dmatlack.bounces.google.com
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="ZeOzaDSq"
Received: by mail-pg1-f202.google.com with SMTP id 41be03b00d2f7-bce224720d8so6626021a12.1
        for <linux-kernel@vger.kernel.org>; Thu, 28 May 2026 10:41:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1779990109; x=1780594909; darn=vger.kernel.org;
        h=cc:to:from:subject:message-id:references:mime-version:in-reply-to
         :date:from:to:cc:subject:date:message-id:reply-to;
        bh=zI6/R1kae2LnDj1mKhlFVbr6Z6bSt4LSCoOlMnq3wXg=;
        b=ZeOzaDSqRX1y5YzTW4R7Y1T99rTFReXuQzNvAE3A5wZ2NYWBN8mPBzxLRaXKjNje4/
         3voULJaBBYUfePI+ae6HfP3buM0TDradoGAcS6YUqnLrwTct73RCjopmH0kOT/dsdYRB
         BQj/5zSxzSiL37KNNAvR8OmgZXDS+P1KVED1c2UeBapjvdcq1779aI66ir6XlaBcYr8h
         wmAZiqqww1fMJthck/8viPtlFMWElWfD7CyAIUgsUX73sG8hAKVGD+m0ACWxL+pgs+I6
         Dl99biTYbZgAgsFhIPkPMSB34SmAFUTyREbd4HNNvf4RiP4+3gYnKhDawSRv4vL03GN6
         VI9Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1779990109; x=1780594909;
        h=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;
        bh=zI6/R1kae2LnDj1mKhlFVbr6Z6bSt4LSCoOlMnq3wXg=;
        b=nnkYkhcs2udDzeKH0D2N9/MhlZ8gV2bCFilYqNmtT4o8g6zUD0rj33gAiK16exdrH4
         riHN0MQYQSiUcCGFVsu+Dg4deOGyCLUujaXKVJl0/ixAwaW9ppUUb/2H+v2u59cX6uyD
         8eabs4VPCfO5rdcWZeGKNjnINF45AVM9mfF0QtztGG96TrlHth6uUwd5f5lGWwZOlCDv
         QObkxqjx3uDH/Kw3EFZPN6FHB7KqtplZRfmutE+MGtvw9WahGtb4E7tjGUDkn3CTei91
         OSAMYVQPArMFMS0kFmWZz43EejEvkbGGBLi7t77mVydjfhqS41WJ5PIzR3xCosFs5l7g
         3siQ==
X-Forwarded-Encrypted: i=1; AFNElJ96af7+AtlQOh89EfKMyIqGN3fLd6KzXB2CyStK5LSkQGekJEtvz26xHsaA0NnckZ5v7mrGRq8KFsvSWqI=@vger.kernel.org
X-Gm-Message-State: AOJu0Yw9mOsdWpbXYC0qNGZqUM2r8Y32SUezTJW1FxoL9OynB1aep2S1
	N/jxfQfsiyq7yvLcrpb97LCIGKx6bYnGUuL1JYuqTcUYUP0k+/FAnvFTKt94jo++hJPSwkLMAM6
	xGmmhVUmBawHvsw==
X-Received: from pgli34.prod.google.com ([2002:a63:1322:0:b0:c82:3bf0:91df])
 (user=dmatlack job=prod-delivery.src-stubby-dispatcher) by
 2002:a05:6a21:394c:b0:3a3:33bd:319b with SMTP id adf61e73a8af0-3b328f3b012mr30313814637.39.1779990109127;
 Thu, 28 May 2026 10:41:49 -0700 (PDT)
Date: Thu, 28 May 2026 17:41:40 +0000
In-Reply-To: <20260528174140.1921129-1-dmatlack@google.com>
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
Mime-Version: 1.0
References: <20260528174140.1921129-1-dmatlack@google.com>
X-Mailer: git-send-email 2.54.0.823.g6e5bcc1fc9-goog
Message-ID: <20260528174140.1921129-3-dmatlack@google.com>
Subject: [PATCH 2/2] liveupdate: Remember FLB retrieve() status
From: David Matlack <dmatlack@google.com>
To: kexec@lists.infradead.org, linux-kernel@vger.kernel.org
Cc: Andrew Morton <akpm@linux-foundation.org>, Mike Rapoport <rppt@kernel.org>, 
	Pasha Tatashin <pasha.tatashin@soleen.com>, Pratyush Yadav <pratyush@kernel.org>, 
	David Matlack <dmatlack@google.com>
Content-Type: text/plain; charset="UTF-8"

LUO keeps track of successful retrieve attempts on an FLB. It does so
to avoid multiple retrievals of the same FLB. Multiple retrievals cause
problems because once the FLB is retrieved, the serialized data
structures are likely freed and the FLB is likely in a very different
state from what the code expects.

All this works well when retrieve succeeds. When it fails,
luo_flb_retrieve_one() returns the error immediately, without ever
storing anywhere that a retrieve was attempted or what its error code
was. If the user attempts to retrieve another file registered with the
same FLB, LUO will attempt to call the FLB's retrieve() callback again.

The retry is problematic for much of the same reasons listed above. The
FLB is likely in a very different state than what the retrieve logic
normally expects (e.g. some KHO pages may have already been restored and
freed).

There is no sane way of attempting the retrieve again. Remember the
error retrieve returned and directly return it on a retry.

This is done by changing the retrieved bool to a retrieve_status
integer. A value of 0 means retrieve was never attempted, a positive
value means it succeeded, and a negative value means it failed and the
error code is the value.

This is similar to commit f85b1c6af5bc ("liveupdate: luo_file: remember
retrieve() status") which did the same for LUO files.

Fixes: cab056f2aae7 ("liveupdate: luo_flb: introduce File-Lifecycle-Bound global state")
Assisted-by: Gemini:gemini-3-pro-preview
Signed-off-by: David Matlack <dmatlack@google.com>
---
 include/linux/liveupdate.h  |  6 ++++--
 kernel/liveupdate/luo_flb.c | 10 +++++++---
 2 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/include/linux/liveupdate.h b/include/linux/liveupdate.h
index c344bf987b63..63ea5417de84 100644
--- a/include/linux/liveupdate.h
+++ b/include/linux/liveupdate.h
@@ -173,7 +173,9 @@ struct liveupdate_flb_ops {
  * @lock:      A mutex that protects all fields within this structure, providing
  *             the synchronization service for the FLB's ops.
  * @finished:  True once the FLB's finish() callback has run.
- * @retrieved: True once the FLB's retrieve() callback has run.
+ * @retrieve_status: Status code indicating whether retrieve() has been
+ *                   attempted. 0 means not attempted, 1 means successful,
+ *                   and negative value means it failed with that error code.
  */
 struct luo_flb_private_state {
 	refcount_t count;
@@ -181,7 +183,7 @@ struct luo_flb_private_state {
 	void *obj;
 	struct mutex lock;
 	bool finished;
-	bool retrieved;
+	int retrieve_status;
 };
 
 /*
diff --git a/kernel/liveupdate/luo_flb.c b/kernel/liveupdate/luo_flb.c
index 7ddef552ff6b..f8852f7e62e5 100644
--- a/kernel/liveupdate/luo_flb.c
+++ b/kernel/liveupdate/luo_flb.c
@@ -170,7 +170,10 @@ static int luo_flb_retrieve_one(struct liveupdate_flb *flb)
 	if (private->incoming.finished)
 		return -ENODATA;
 
-	if (private->incoming.retrieved)
+	if (private->incoming.retrieve_status < 0)
+		return private->incoming.retrieve_status;
+
+	if (private->incoming.retrieve_status > 0)
 		return 0;
 
 	if (!fh->active)
@@ -196,12 +199,13 @@ static int luo_flb_retrieve_one(struct liveupdate_flb *flb)
 
 	err = flb->ops->retrieve(&args);
 	if (err) {
+		private->incoming.retrieve_status = err;
 		module_put(flb->ops->owner);
 		return err;
 	}
 
 	private->incoming.obj = args.obj;
-	private->incoming.retrieved = true;
+	private->incoming.retrieve_status = 1;
 
 	return 0;
 }
@@ -215,7 +219,7 @@ void liveupdate_flb_put_incoming(struct liveupdate_flb *flb)
 		if (!refcount_dec_and_test(&private->incoming.count))
 			return;
 
-		if (!private->incoming.retrieved) {
+		if (private->incoming.retrieve_status <= 0) {
 			int err = luo_flb_retrieve_one(flb);
 
 			if (WARN_ON(err))
-- 
2.54.0.823.g6e5bcc1fc9-goog


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 7F8E23F58EB
	for <linux-kernel@vger.kernel.org>; Tue,  2 Jun 2026 17:15:08 +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=1780420509; cv=none; b=F7bCKQxBwNnLEJswvNJyEdnWryiSjd4Q1xeSgUn+UASJTrw+mOQTr5iNBalA+OSrlB1qB69mlhXRHh4m/fkNcUE9e98n3EWi7JOD1BjK2tdvl58obNu/dTJHaXjwOHSthRc3TeiDH/3t60LGCt/oynvPUJO+qXpTWPNQyFed8XA=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1780420509; c=relaxed/simple;
	bh=SAgJuH62Ge/nPwkssEVPzKPhgfSZrn2HgIs8IVwFc0o=;
	h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID:
	 MIME-Version:Content-Type; b=YCJ8MsOPrAU0UoxrHIncaRv+Q6Zw9BJo054z2yVC0Ymtor+4jn3b1lkKS4xRd/IQNFq59Jsjz4g4a7vFrwbAVj2r2eL4aQEF3+vW9JVGZO4toUssVsMn4qkIM5l1U+Mm/PIs1c8t1D1EUv6Vgae9HtashX62qF31MXz/8cw7EDA=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=hsYhUdN5; 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="hsYhUdN5"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id E9CAB1F00893;
	Tue,  2 Jun 2026 17:15:06 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org;
	s=k20260515; t=1780420508;
	bh=+opkI2D1z70JJ/vyXa1VmjlNB/odsO3As2SLbmif/rE=;
	h=From:To:Cc:Subject:In-Reply-To:References:Date;
	b=hsYhUdN5KKWG43obmuWABfJvvB+ewozEiyAcEJkrqVowvYeX4Sbhkv/ZHsNCsCL0C
	 PuEq3PPixA9x5tQNrGdlZjMs/nfvUuC06QjE2Y7cB0yeUtylrbCbLbF1WPchcNr456
	 YREdjfcjh7jLC+4h3dZpTZYmIp8EQq+TFjuw7bgAbb4H55GQqNBOCPFO/VIOQSIRlk
	 sHMehCjbFbsOZhYgNlcp6gZG3QDfmAlKl46iY0wLWObVA2zJd+cJ8b5eaT1A3duByi
	 q3Xrt86L2n2fGNrpfS2HM51AHoMOKw2VCEPZOgWRjnJk2Rj10j6rc3keb/W+LO08Q6
	 GkKnaVMxdyDMA==
From: Pratyush Yadav <pratyush@kernel.org>
To: David Matlack <dmatlack@google.com>
Cc: kexec@lists.infradead.org,  linux-kernel@vger.kernel.org,  Andrew Morton
 <akpm@linux-foundation.org>,  Mike Rapoport <rppt@kernel.org>,  Pasha
 Tatashin <pasha.tatashin@soleen.com>,  Pratyush Yadav
 <pratyush@kernel.org>
Subject: Re: [PATCH 1/2] liveupdate: Reference count outgoing FLB data
In-Reply-To: <20260528174140.1921129-2-dmatlack@google.com> (David Matlack's
	message of "Thu, 28 May 2026 17:41:39 +0000")
References: <20260528174140.1921129-1-dmatlack@google.com>
	<20260528174140.1921129-2-dmatlack@google.com>
Date: Tue, 02 Jun 2026 19:15:05 +0200
Message-ID: <2vxzfr34dfty.fsf@kernel.org>
User-Agent: Gnus/5.13 (Gnus v5.13)
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain

Hi David,

On Thu, May 28 2026, David Matlack wrote:

> Increment the outgoing FLB refcount in liveupdate_flb_get_outgoing() so
> that the FLB structure cannot be freed while the caller is actively
> using it. Add an additional liveupdate_flb_put_outgoing() function so
> the caller can explicitly indicate when it is done using the outgoing
> FLB.
>
> During a Live Update, the kernel may need to fetch the outgoing FLB
> outside of the scope of a file handler's preserve() and unpreserve()
> callbacks. In that situation there is no way for the caller to protect
> itself against the outgoing FLB from being freed while it is using it.
> Incrementing the reference count in liveupdate_flb_get_outgoing()
> ensures it cannot be freed.

We grab a reference to the FLB's module when the first file using the
FLB is preserved. So the FLB should never go away while preserved files
exist. Once all preserved files go away, you normally shouldn't be doing
anything with the FLB anyway.

Can you please elaborate on the use case and why this is a problem?
Using the FLB outside of the standard LUO file callbacks sounds
problematic.

>
> This change also aligns the outgoing FLB lifecycle management with the
> incoming FLB, since the latter uses the same get/put semantics.
>
> Fixes: cab056f2aae7 ("liveupdate: luo_flb: introduce File-Lifecycle-Bound global state")
> Assisted-by: Gemini:gemini-3-pro-preview
> Signed-off-by: David Matlack <dmatlack@google.com>
[...]

-- 
Regards,
Pratyush Yadav

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 54EFB3EAC84
	for <linux-kernel@vger.kernel.org>; Tue,  2 Jun 2026 17:18:21 +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=1780420702; cv=none; b=mgHP2YBz5+7jxFpQIqLAfVqoYSBX1N6EbXii2UUib3fUK67x6kRVNU16UURqoYK3Y6POQP5R00ud9IMwx8MqYWRTGSb7+5Vfr1kGr+i5gyIvTXTXk4yjqZorJmHs6KRCfLsh9e4LW0bZTjq/NOLquxwXU7vdwpy5r2ogLxp6nB4=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1780420702; c=relaxed/simple;
	bh=d9PrBPcw1dzU+vwnStPPv2NGQi2H2lcLA7uJC7CXEXQ=;
	h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID:
	 MIME-Version:Content-Type; b=sgMcUCf4aWG8snBFV3a4kMyF0Te7Qqmjcha0dc1xw3fTzTFUXxNb4rb3V6lvorKePG+8EAWtj3IzGffijJUmwwrokWyuOcSBAxnxWpviyfxdvNvj1GmiE5P5EjfPPg6wSnrg0mMgeDgjjUXXhhNQSzobHw4I+LUYIl3c7x2zuoo=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ZBxrHBw6; 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="ZBxrHBw6"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id BAE2C1F00893;
	Tue,  2 Jun 2026 17:18:19 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org;
	s=k20260515; t=1780420701;
	bh=D0Boguu0LesyWMHeJhzuparvQJGWjUOs54nvxOhsjj8=;
	h=From:To:Cc:Subject:In-Reply-To:References:Date;
	b=ZBxrHBw6VSwU1zg4uqbpFnH3K0w7m+VvpVuAbGTdRTiPirUpWt1BSpygDe1jF3Jsw
	 DvSsjdRlSHSDpZdFuvh/R/QyaC+wlVWWftrQEaqhmW18agJn0ay/I8YcGm5Rqw35dg
	 V4+xQuLSIaXuA90whmsDlQq/PIv5Bwlt76TXLPyD2Xy3Q7kLiRamRafwkwMbehFxpm
	 t6S+lZSE1exIY/EdwMVwwmljjLcnJ/KsxhLODXEf5gm6NiZ8N7VFKFDvdOUKHKU9Nm
	 WyLnqK0gektVM6OMrhQf6W4ZqeheKqEB3zozTPfDMEc/0p3BVqxdyyqOXfm+HVJDaD
	 pGToyiFVGhFfw==
From: Pratyush Yadav <pratyush@kernel.org>
To: David Matlack <dmatlack@google.com>
Cc: kexec@lists.infradead.org,  linux-kernel@vger.kernel.org,  Andrew Morton
 <akpm@linux-foundation.org>,  Mike Rapoport <rppt@kernel.org>,  Pasha
 Tatashin <pasha.tatashin@soleen.com>,  Pratyush Yadav
 <pratyush@kernel.org>
Subject: Re: [PATCH 2/2] liveupdate: Remember FLB retrieve() status
In-Reply-To: <20260528174140.1921129-3-dmatlack@google.com> (David Matlack's
	message of "Thu, 28 May 2026 17:41:40 +0000")
References: <20260528174140.1921129-1-dmatlack@google.com>
	<20260528174140.1921129-3-dmatlack@google.com>
Date: Tue, 02 Jun 2026 19:18:18 +0200
Message-ID: <2vxzbjdsdfol.fsf@kernel.org>
User-Agent: Gnus/5.13 (Gnus v5.13)
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain

On Thu, May 28 2026, David Matlack wrote:

> LUO keeps track of successful retrieve attempts on an FLB. It does so
> to avoid multiple retrievals of the same FLB. Multiple retrievals cause
> problems because once the FLB is retrieved, the serialized data
> structures are likely freed and the FLB is likely in a very different
> state from what the code expects.
>
> All this works well when retrieve succeeds. When it fails,
> luo_flb_retrieve_one() returns the error immediately, without ever
> storing anywhere that a retrieve was attempted or what its error code
> was. If the user attempts to retrieve another file registered with the
> same FLB, LUO will attempt to call the FLB's retrieve() callback again.
>
> The retry is problematic for much of the same reasons listed above. The
> FLB is likely in a very different state than what the retrieve logic
> normally expects (e.g. some KHO pages may have already been restored and
> freed).
>
> There is no sane way of attempting the retrieve again. Remember the
> error retrieve returned and directly return it on a retry.
>
> This is done by changing the retrieved bool to a retrieve_status
> integer. A value of 0 means retrieve was never attempted, a positive
> value means it succeeded, and a negative value means it failed and the
> error code is the value.
>
> This is similar to commit f85b1c6af5bc ("liveupdate: luo_file: remember
> retrieve() status") which did the same for LUO files.
>
> Fixes: cab056f2aae7 ("liveupdate: luo_flb: introduce File-Lifecycle-Bound global state")
> Assisted-by: Gemini:gemini-3-pro-preview
> Signed-off-by: David Matlack <dmatlack@google.com>

Reviewed-by: Pratyush Yadav (Google) <pratyush@kernel.org>

Thanks for fixing this!

[...]

-- 
Regards,
Pratyush Yadav

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail-pl1-f177.google.com (mail-pl1-f177.google.com [209.85.214.177])
	(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 207EE2DECCB
	for <linux-kernel@vger.kernel.org>; Tue,  2 Jun 2026 17:25:39 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.177
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1780421141; cv=none; b=M7/lb4yPA1qBkFiuPfldxxdqVNIcRfvtHTPTDVmTaoywfc+eyCcqeOmVzmPfR7u5VspAQo0Q02jyYd2kxQFxeTOLAnslieUKqXmNSvhU3pwce5JdRwDdQkp1txLAnMlPrHH6wlIs0ZWojkptFOoujMiBt6+GGNEw6fG/je6d2Hs=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1780421141; c=relaxed/simple;
	bh=kFqYH8KnSVjiIhsPRKdCdRgjUg0DI+7HiUNHazXd1RU=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	 Content-Type:Content-Disposition:In-Reply-To; b=uOgrwdh18NWPG/hng7pWxWfL8iGye5cLHLwAyZjWcUF+OxnylprGevYxdJXexivZx40hoXL0rKN+g4MP75/Mpec1aZIFtbFOADwL/iDqXBMpb+jdWx3VRnyCZj0u6v6V1hSI+6dp2UX6ObhnMcSodQiXqrN5HCHBUwgOZDSFHYw=
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=a0pTutNt; arc=none smtp.client-ip=209.85.214.177
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="a0pTutNt"
Received: by mail-pl1-f177.google.com with SMTP id d9443c01a7336-2c0c2a68d01so18095345ad.1
        for <linux-kernel@vger.kernel.org>; Tue, 02 Jun 2026 10:25:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1780421139; x=1781025939; 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=2orsdr+v6yIbfcC4d109Ztib1WHfFanWjEmldcE7TJ4=;
        b=a0pTutNtVllzuN98fbHl3xtVXoHUFqPRQ3nncwKbjV75O+knGYVBFDm6l2vd5eE1WC
         lu7ewNpvY0pdBp46pkL6lYszEtV2w+mVZvoObwQGdTU2HwECl9fPsmCwz/pk0KHzYxxa
         fcjOk4RtfNfqA7JGVWWRd2fMVU9jW01DMr0vTkD1T33nmcY3m2DRsSoFttKvZjijhRQq
         I6T1uabEiy+y7HHdvaxFq7D1ALo7wwZIMf2E885QaAM/mHaaPxZvMLSPJFN5O8OyA0p1
         wFOM7DX2ZsZgph7u/ynoY4/OaLAEIVu3lIBqY8h6CreXbU/15ymxW/90HXj9AnUOQuun
         RBaw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1780421139; x=1781025939;
        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=2orsdr+v6yIbfcC4d109Ztib1WHfFanWjEmldcE7TJ4=;
        b=gt1Nu43ivWEf6cR6i2dtygbQeuHJln+F+u8rML8ihg+gsCAiNvJIL7gTObbp1Ao+lz
         FrPPPcGIFxeIgqBfzAd4HUdUgttKEYGnpFSIUjHTAYnY/zbP2B2SvqzwnPcwg6792t6A
         TA8xIQt30dQHwp946caF9cKZ9Oe98u75zOK6UXfqU6hPPZZHhs6vOQ5l+EDRNiPImhgl
         7d8F0xFWzbHmwK3h9Nb/DE6kpxIuQr6VNUzXSe6GuXTrYgLAK1hJ64QxUVn921tjmOaX
         B0XMBxYORSCewcCqVPx4lKNSWi878LKuyEf8xfdtL1LzeikdvPqZnE+EAKaFv3OcZGHW
         CgLA==
X-Forwarded-Encrypted: i=1; AFNElJ8+YYF56Janp1Fk9yC7pw87z2BrWL9mX5d52VeFrguu/Y5T+UTbQw6Vk6LWjxa9NOhQ7NvlyMAfViwKiG0=@vger.kernel.org
X-Gm-Message-State: AOJu0Ywr4CDt6917EiRuRcrZWovQeWjde7CLr7Tq0qv4bFPNc+5GvUBo
	S2AD1K2xLWRVpSSFkXldjNIZAu/S8antHabcby5dW/gyxxpVqUMPjVAy5yZEhG0hgg==
X-Gm-Gg: Acq92OH/pp1mc7EgbU+bD+6bGWmSQveNLpog0TpOAiRlXQRBBKGLmCFwuVe1TyfpmEQ
	zGs1UxXgooPrmk95vb643vCO6YOC1h/0H/yFtfBDORdLJUPY1JEKbo/RLvhA7m/NjWPuTSytJgM
	uLiWFSl9exbW0Id4Y5vsKZNXQXuMx7Cak/M+KCSyd8Lyq1cNvlxKpdpdFNF+kIqgRy8iBWNXGcj
	ZWe6vBPnMV85iSx4njQEW+FHAwclxxOXC2D+pT5a3lirbCHMetsJesrO9ZPyvoASzENWFDWY1JE
	ppKk3IDbVWkcpvX14NYm+MseEH0bjhJ5kP37AiV2iCaoU8GhqmabOtYBgxDbOzyaFGOhfpYtYqS
	mndJUZQol008pJAyGp7styDTjdk911wRNJ+nm+CG7gVT4Cd+VXE2EUswep3qF7wn1z6ZuJsgZHO
	nzK+WFeaHRBex4H7wSyUbMe7lTYEGw36y3o89UCoWJ3eW7uv4NyYOrIYmLrwbinGDqaWgC8zPI
X-Received: by 2002:a17:903:390c:b0:2c0:c625:4001 with SMTP id d9443c01a7336-2c0c6254226mr131813415ad.39.1780421138788;
        Tue, 02 Jun 2026 10:25:38 -0700 (PDT)
Received: from google.com (56.149.168.34.bc.googleusercontent.com. [34.168.149.56])
        by smtp.gmail.com with ESMTPSA id d9443c01a7336-2bf23b01214sm141692365ad.50.2026.06.02.10.25.38
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Tue, 02 Jun 2026 10:25:38 -0700 (PDT)
Date: Tue, 2 Jun 2026 17:25:34 +0000
From: David Matlack <dmatlack@google.com>
To: Pratyush Yadav <pratyush@kernel.org>
Cc: kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Mike Rapoport <rppt@kernel.org>,
	Pasha Tatashin <pasha.tatashin@soleen.com>
Subject: Re: [PATCH 1/2] liveupdate: Reference count outgoing FLB data
Message-ID: <ah8SDsIuZQXyvpZq@google.com>
References: <20260528174140.1921129-1-dmatlack@google.com>
 <20260528174140.1921129-2-dmatlack@google.com>
 <2vxzfr34dfty.fsf@kernel.org>
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2vxzfr34dfty.fsf@kernel.org>

On 2026-06-02 07:15 PM, Pratyush Yadav wrote:
> Hi David,
> 
> On Thu, May 28 2026, David Matlack wrote:
> 
> > Increment the outgoing FLB refcount in liveupdate_flb_get_outgoing() so
> > that the FLB structure cannot be freed while the caller is actively
> > using it. Add an additional liveupdate_flb_put_outgoing() function so
> > the caller can explicitly indicate when it is done using the outgoing
> > FLB.
> >
> > During a Live Update, the kernel may need to fetch the outgoing FLB
> > outside of the scope of a file handler's preserve() and unpreserve()
> > callbacks. In that situation there is no way for the caller to protect
> > itself against the outgoing FLB from being freed while it is using it.
> > Incrementing the reference count in liveupdate_flb_get_outgoing()
> > ensures it cannot be freed.
> 
> We grab a reference to the FLB's module when the first file using the
> FLB is preserved. So the FLB should never go away while preserved files
> exist. Once all preserved files go away, you normally shouldn't be doing
> anything with the FLB anyway.
> 
> Can you please elaborate on the use case and why this is a problem?
> Using the FLB outside of the standard LUO file callbacks sounds
> problematic.

The scenario I had in mind was to remove a PCI device from the outgoing
FLB if the device is forcibly removed while the file is still preserved,
for example someone writes 1 to /sys/bus/pci/devices/.../remove or a
device is physically hot-unplugged.

Specifically this call here from the patch below:

+void pci_liveupdate_cleanup_device(struct pci_dev *dev)
+{
+	/*
+	 * It should be safe to READ_ONCE() outside of the rwsem during cleanup
+	 * since there should no longer be any references to @dev on the system.
+	 */
+	if (READ_ONCE(dev->liveupdate.outgoing)) {
+		pci_WARN(dev, 1, "Destroying outgoing-preserved device!\n");
+		pci_liveupdate_unpreserve(dev);
+	}
+}

https://lore.kernel.org/linux-pci/20260522202410.3104264-3-dmatlack@google.com/

I can do this without adding reference counting to
liveupdate_flb_get_outgoing(), but the reference counting makes it
obvious that the outgoing FLB will not be freed while I am using it
here, and also aligns with liveupdate_flb_get_incoming().

> >
> > This change also aligns the outgoing FLB lifecycle management with the
> > incoming FLB, since the latter uses the same get/put semantics.
> >
> > Fixes: cab056f2aae7 ("liveupdate: luo_flb: introduce File-Lifecycle-Bound global state")
> > Assisted-by: Gemini:gemini-3-pro-preview
> > Signed-off-by: David Matlack <dmatlack@google.com>
> [...]
> 
> -- 
> Regards,
> Pratyush Yadav

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail-qv1-f49.google.com (mail-qv1-f49.google.com [209.85.219.49])
	(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 E67292D0620
	for <linux-kernel@vger.kernel.org>; Wed,  3 Jun 2026 03:36:19 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.49
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1780457781; cv=none; b=bXykTcNhj1sOEY94Cj2frHlODhgh0QEmQpY13GmXgncedumnCA6m7MGNHZ7RZrhXXpCqJA9y2ZxiiWIefOUsa2XUTetPTw+bxmQPhkzjl6qA3MTvy7lVpc7lHqNE1RTEZ/EYwLLp/Zo2j8IaXYy45dMXA4I1RMVMdWlTJ1aI5t8=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1780457781; c=relaxed/simple;
	bh=noOVctoYLEpp5/tFmimRHVYFFJBZUnwifX9RyyUloZ4=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	 Content-Type:Content-Disposition:In-Reply-To; b=gsRnnkSe8O3Rnvolx3y5prGIRVFRon/WIMzsBdwgf0vJ9lIoBXP6N5I2AQ4iNzRhJ6FYDIiBvTTBoxt5HRw5zODJrJb3JpxgC9THkjYibaES8l4MOamQffuQ14K3i6UZL22DnWfUSGusMo0KfQ7qqE0Xqr5/SWFhWdvwPZO/XR8=
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=gRh227QF; arc=none smtp.client-ip=209.85.219.49
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="gRh227QF"
Received: by mail-qv1-f49.google.com with SMTP id 6a1803df08f44-8cceaa6f75bso77470886d6.0
        for <linux-kernel@vger.kernel.org>; Tue, 02 Jun 2026 20:36:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=soleen.com; s=google; t=1780457779; x=1781062579; 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=FAC+XywUjSvRcC/lmO2OhZjlflNjORbFaO72oWGwvQo=;
        b=gRh227QFDV2MZY5onYTh7KGRhVlSyJpJNEpnTbHtRAean1NwNpbS3NvBuRr91yXNXE
         7VEBUkbNOX2jbJ4LtZpsXZw0jl4g9VD6bQJtXkIstazmTXOeyfZLHKW4tHQ4jsG7kXE2
         J3klAWdAFiCPuW030iIqPDnIqgD8CBELJmxZHzEUupOzToj/zAP8qOYmiLDKIdJZD+n9
         p89nJMrqMPfQWs/3h7FvjF/OLjCO228UiSkuHMbtwR6sAoRizPGPXLxLv+kAXb3NKadf
         2V4xQxfc1QWQSyyn+t0NEUQT8iQIOWIABULljEusHKXJkUbSywUx8YvgrC3V4j1GlKOA
         rDTA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1780457779; x=1781062579;
        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=FAC+XywUjSvRcC/lmO2OhZjlflNjORbFaO72oWGwvQo=;
        b=tH2asxDJpSTRUV6B59VedB0dOmnT1aHGjg6BAv5iOXKecplluVozSflzp34iLCh3Cw
         TPsb9rcqbBZUQFoDJi8xG7v6OCFSDScqvpOsa98IybkLlZF/LjHAiquGCnmDSV5gT8mF
         +lsVgI/inQjdYICiQfUaq3xlBWMedTOnYiX4if82otBjodnpFXmHq3OwOW2bBjUsjxEv
         YypSd/we9RQ9j3QJrK5jrOJkNS96XTvHLmjTvl1R72EW4F+BjOmgueaNGIAybLseg0uP
         UfSuwbFvVaS11y+ZuWFmk+agjG7nQmGX7b5kIYNwp4BDKLOhKT3P7z8JjUa/I/21qKhM
         dpcg==
X-Forwarded-Encrypted: i=1; AFNElJ/nRM1lAPzn3ff/Ly3s1KJ3Gt/WOSaUFbWDIF+vokX3i6hlHfS2Uvj/hicByOKxTBcxmjQN1lFyN8/GtcA=@vger.kernel.org
X-Gm-Message-State: AOJu0YxwPvT6xNgT5/1vwAykdycG8NQB/0odO3zOJ7XckF0BafPCYvYB
	CH3v5nO+pVJcPe0N/rta0ZgHwHiisxxxPIUveT0NfI1lpmXMsKZTcdq5nESP7FC7GSzMWGdTVAl
	gBkR3
X-Gm-Gg: Acq92OHMubjmnbuosJHrBs2k3IKspbpvLCpZ9H6JC9vW5/e3nZx7ejZL7DyLkdCKMH3
	aeQ/pEVXmRQ/RTInsAUZM0xZD6Ci2Gqr84e2jzKzh3JIVhBcBkPXCllra/yshvLOGs61XVjaN0K
	xiU9feo/Bkg8+zSEoZNf7zIXlP9btSGUIru8qCQckpAwtRXICAuPVBW9XOjqTJveuthFkO3bfmc
	8JFdNSrSfF8b12DWEKH2Q6L1NLB4OwoO/uubO56sQnk5RyUMTxMpCNqv6Y5aidLet0fOde7M6gK
	FB3p6QuvqSToauvNAfGxmQvPbpR0pa6sCBAx52tNrNpuOqldJY//IUKFSLJUXYb5RjIOg73fTmK
	VIu6cq26eGfK8WLn+N1FtFv65mbwuIhY3RaTaezuX9klfRNAlCeoWomIyBhShKvWT2xzYpwVeHo
	tsWJEZYE0v/+w4jDkreo6q/cGOCsmDvvySxtdqxKzUx0pZT54sRQeFfvkb6tsKATRW6o2eqSsR
X-Received: by 2002:a05:6214:dce:b0:8cc:ead5:f377 with SMTP id 6a1803df08f44-8cece16781emr20800526d6.38.1780457779010;
        Tue, 02 Jun 2026 20:36:19 -0700 (PDT)
Received: from plex ([71.181.43.54])
        by smtp.gmail.com with ESMTPSA id 6a1803df08f44-8ceccda2601sm9573956d6.6.2026.06.02.20.36.17
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Tue, 02 Jun 2026 20:36:18 -0700 (PDT)
Date: Wed, 3 Jun 2026 03:36:17 +0000
From: Pasha Tatashin <pasha.tatashin@soleen.com>
To: David Matlack <dmatlack@google.com>
Cc: kexec@lists.infradead.org, linux-kernel@vger.kernel.org, 
	Andrew Morton <akpm@linux-foundation.org>, Mike Rapoport <rppt@kernel.org>, 
	Pasha Tatashin <pasha.tatashin@soleen.com>, Pratyush Yadav <pratyush@kernel.org>
Subject: Re: [PATCH 2/2] liveupdate: Remember FLB retrieve() status
Message-ID: <ah-hG1TObQ3PCtd-@plex>
References: <20260528174140.1921129-1-dmatlack@google.com>
 <20260528174140.1921129-3-dmatlack@google.com>
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20260528174140.1921129-3-dmatlack@google.com>

On 05-28 17:41, David Matlack wrote:
> LUO keeps track of successful retrieve attempts on an FLB. It does so
> to avoid multiple retrievals of the same FLB. Multiple retrievals cause
> problems because once the FLB is retrieved, the serialized data
> structures are likely freed and the FLB is likely in a very different
> state from what the code expects.
> 
> All this works well when retrieve succeeds. When it fails,
> luo_flb_retrieve_one() returns the error immediately, without ever
> storing anywhere that a retrieve was attempted or what its error code
> was. If the user attempts to retrieve another file registered with the
> same FLB, LUO will attempt to call the FLB's retrieve() callback again.
> 
> The retry is problematic for much of the same reasons listed above. The
> FLB is likely in a very different state than what the retrieve logic
> normally expects (e.g. some KHO pages may have already been restored and
> freed).
> 
> There is no sane way of attempting the retrieve again. Remember the
> error retrieve returned and directly return it on a retry.
> 
> This is done by changing the retrieved bool to a retrieve_status
> integer. A value of 0 means retrieve was never attempted, a positive
> value means it succeeded, and a negative value means it failed and the
> error code is the value.
> 
> This is similar to commit f85b1c6af5bc ("liveupdate: luo_file: remember
> retrieve() status") which did the same for LUO files.
> 
> Fixes: cab056f2aae7 ("liveupdate: luo_flb: introduce File-Lifecycle-Bound global state")
> Assisted-by: Gemini:gemini-3-pro-preview
> Signed-off-by: David Matlack <dmatlack@google.com>

Reviewed-by: Pasha Tatashin <pasha.tatashin@soleen.com> 

> ---
>  include/linux/liveupdate.h  |  6 ++++--
>  kernel/liveupdate/luo_flb.c | 10 +++++++---
>  2 files changed, 11 insertions(+), 5 deletions(-)
> 
> diff --git a/include/linux/liveupdate.h b/include/linux/liveupdate.h
> index c344bf987b63..63ea5417de84 100644
> --- a/include/linux/liveupdate.h
> +++ b/include/linux/liveupdate.h
> @@ -173,7 +173,9 @@ struct liveupdate_flb_ops {
>   * @lock:      A mutex that protects all fields within this structure, providing
>   *             the synchronization service for the FLB's ops.
>   * @finished:  True once the FLB's finish() callback has run.
> - * @retrieved: True once the FLB's retrieve() callback has run.
> + * @retrieve_status: Status code indicating whether retrieve() has been
> + *                   attempted. 0 means not attempted, 1 means successful,
> + *                   and negative value means it failed with that error code.
>   */
>  struct luo_flb_private_state {
>  	refcount_t count;
> @@ -181,7 +183,7 @@ struct luo_flb_private_state {
>  	void *obj;
>  	struct mutex lock;
>  	bool finished;
> -	bool retrieved;
> +	int retrieve_status;
>  };
>  
>  /*
> diff --git a/kernel/liveupdate/luo_flb.c b/kernel/liveupdate/luo_flb.c
> index 7ddef552ff6b..f8852f7e62e5 100644
> --- a/kernel/liveupdate/luo_flb.c
> +++ b/kernel/liveupdate/luo_flb.c
> @@ -170,7 +170,10 @@ static int luo_flb_retrieve_one(struct liveupdate_flb *flb)
>  	if (private->incoming.finished)
>  		return -ENODATA;
>  
> -	if (private->incoming.retrieved)
> +	if (private->incoming.retrieve_status < 0)
> +		return private->incoming.retrieve_status;
> +
> +	if (private->incoming.retrieve_status > 0)
>  		return 0;
>  
>  	if (!fh->active)
> @@ -196,12 +199,13 @@ static int luo_flb_retrieve_one(struct liveupdate_flb *flb)
>  
>  	err = flb->ops->retrieve(&args);
>  	if (err) {
> +		private->incoming.retrieve_status = err;
>  		module_put(flb->ops->owner);
>  		return err;
>  	}
>  
>  	private->incoming.obj = args.obj;
> -	private->incoming.retrieved = true;
> +	private->incoming.retrieve_status = 1;
>  
>  	return 0;
>  }
> @@ -215,7 +219,7 @@ void liveupdate_flb_put_incoming(struct liveupdate_flb *flb)
>  		if (!refcount_dec_and_test(&private->incoming.count))
>  			return;
>  
> -		if (!private->incoming.retrieved) {
> +		if (private->incoming.retrieve_status <= 0) {
>  			int err = luo_flb_retrieve_one(flb);
>  
>  			if (WARN_ON(err))
> -- 
> 2.54.0.823.g6e5bcc1fc9-goog
> 

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail-qt1-f179.google.com (mail-qt1-f179.google.com [209.85.160.179])
	(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 DC1723F1AA0
	for <linux-kernel@vger.kernel.org>; Wed,  3 Jun 2026 03:36:44 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.179
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1780457806; cv=none; b=re/YfXoIkGg8hy9WsCkmFHpydTUwkkXAsXj28el6P2PjinEcXLn5t3sxqvFUEQwRPBQT9DoirCMikISS3GOGELHPPl7ZM2rrn5cMd9KWGsa2co0JJue/5zmryatKtIME0S8YaiY9F4dnn6is39vmKde/DoYB4IfkXr1a5haMRa0=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1780457806; c=relaxed/simple;
	bh=hlmeRQF19tuuYqjlSs1OAtvups0MEJOffZTY2MaCaT0=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	 Content-Type:Content-Disposition:In-Reply-To; b=Czgvt7uPFfQdzHyxBVVPXk/T6joXe5jnAf8wGE4W80PzsbwVzNkZo+pKARYvvzvtPdzSLE30TmSSOa9bupoglpSJOzMhbY6K7VCMD7DYHsqP2SUCEPzAVJWqLFTtfXZlqR56EZFVbOlqVWs78A5mbctRDNsrvPGkVeGjZM2mFx0=
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=HWgoS6u4; arc=none smtp.client-ip=209.85.160.179
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="HWgoS6u4"
Received: by mail-qt1-f179.google.com with SMTP id d75a77b69052e-5176ca6bab1so2895221cf.0
        for <linux-kernel@vger.kernel.org>; Tue, 02 Jun 2026 20:36:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=soleen.com; s=google; t=1780457804; x=1781062604; 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=19g1dGk4BTOikWiMQOoz6k+1dj4ui8RGk7l8PldXTJ8=;
        b=HWgoS6u45MRVL3gPlAHoM78GlJVkInxgmdQDNcpyO7Ii8OygFHGqgS+MyhlX2dz8Zc
         WYFBrB2BpjJ16/5t2AKveHFS06ArptotD4Rqx2/l9L8uCKGR6MrDTWhK/R2sKD0tNrEo
         ptKlRSFNzT62HLx3CsM2nC9dpgV1k9xN7wX3aGSxl+L6TYfxkELFzlsGt5ArBEzEmFtU
         R3wQd2OubieNiZFDAHaXstgcl5MGcFIz/0Hp320y5au4W8UwyyUFxXQQZ3NHSaNRYKJv
         Ush4qgH+nykvJQ73B2Oh+zEgO6buED7HGdcFtJqtj3zEhnQWrUkyBvjcGDRnpjjUuOqw
         AIGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1780457804; x=1781062604;
        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=19g1dGk4BTOikWiMQOoz6k+1dj4ui8RGk7l8PldXTJ8=;
        b=R20tHhskO4b7buffxA9ONZcREAJ4KE09+dGANThA9F3f4N0xFjpdDc+twJets0gyWO
         sKSdr+q6mTiTFvdi9WA7s915lnSkb3FnYoZpfHvFBrEFjXp2QMj0lDIGwRCrZDzWbr+w
         m6pkmeQHeUYDkUyno3iMutRLQhsD/FVG7tfj+uhstNkfZg1/e3LrsEdekta74dc1wIU7
         OYQQPWeF4yD1yusv4dDGqmyCevWInRFsO+r0IArKabQIMO39Lk+b9QdQS5qxGVsEPPJ5
         lfiKmHJl3cnpwddHKHRdWR86eJdkSEJKgW85Jz7U/ALXG7paxinnLnMMJpMeZM8CTWN4
         rdEQ==
X-Forwarded-Encrypted: i=1; AFNElJ8/Nu0gpUj4Y+54mgWXjau12hlRJsA3Y0M+J5UdZBXNM0F9t4DBnnV7AScqpWEVzUL5olxprYlvn8kbfCY=@vger.kernel.org
X-Gm-Message-State: AOJu0Yxk6j7qQoT8cBG6EmG0i39XIB4G23/YTGXiC2/36Y4aop8h/GRF
	p30nVdpM5QMDGA1N0KyrFrbRupH7smex+/ow9SljzEr7hZrSnzMlf/yxQH89BkhWmtc=
X-Gm-Gg: Acq92OHjFCD89BvifjMybm2KbarUHE5KSUceKqJ8gkOwgNszWXWHlUPLqjqDWa4yzbp
	HKWxMZgv433q2RDqENDI36r8p9hCWXRJQZQy55UVPIm6YL5SxfNX2tDGp33ptClLbLD+tr+7SyA
	/KQu6XN36fqDpkW8jyMe2IJaCYcn0H6N7kWYAPmkJGajEFU4KQ85sVOoP0S71tUPvUhiIC9Xy06
	KwQh16/7tG819cDXTlyHHFYEMHG0YEo2Q3e7MfljAtU6uY7ajjzDXJmSWv9zL1Ix1V/ZoJ7D5j2
	/vVfaqebj1qXrtHIYvQrDsiCqQ7zmFZejfjSUoZQMyUAxrdGMusbfH/xsQxpquOW9L071bN3xuk
	TcP/iM9Fcpy84oZ6j0Lj/vXycGlOiIB02xvg8B65ZL0hc+DIqbGl5k6cXz2sxDTCXWHJP7Gag9H
	eoAwioZRSVZHVEjOVPfSR2jXRVZyl1vonw0b0o44zXL0ktGJkkpW4U6x3pLCJzAw==
X-Received: by 2002:a05:622a:1911:b0:50f:bd19:657b with SMTP id d75a77b69052e-517796cbe0bmr19101691cf.10.1780457803843;
        Tue, 02 Jun 2026 20:36:43 -0700 (PDT)
Received: from plex ([71.181.43.54])
        by smtp.gmail.com with ESMTPSA id d75a77b69052e-51775c07c29sm14969661cf.1.2026.06.02.20.36.37
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Tue, 02 Jun 2026 20:36:38 -0700 (PDT)
Date: Wed, 3 Jun 2026 03:36:37 +0000
From: Pasha Tatashin <pasha.tatashin@soleen.com>
To: David Matlack <dmatlack@google.com>
Cc: kexec@lists.infradead.org, linux-kernel@vger.kernel.org, 
	Andrew Morton <akpm@linux-foundation.org>, Mike Rapoport <rppt@kernel.org>, 
	Pasha Tatashin <pasha.tatashin@soleen.com>, Pratyush Yadav <pratyush@kernel.org>
Subject: Re: [PATCH 1/2] liveupdate: Reference count outgoing FLB data
Message-ID: <ah-hOvBR7QcTshoc@plex>
References: <20260528174140.1921129-1-dmatlack@google.com>
 <20260528174140.1921129-2-dmatlack@google.com>
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20260528174140.1921129-2-dmatlack@google.com>

On 05-28 17:41, David Matlack wrote:
> Increment the outgoing FLB refcount in liveupdate_flb_get_outgoing() so
> that the FLB structure cannot be freed while the caller is actively
> using it. Add an additional liveupdate_flb_put_outgoing() function so
> the caller can explicitly indicate when it is done using the outgoing
> FLB.
> 
> During a Live Update, the kernel may need to fetch the outgoing FLB
> outside of the scope of a file handler's preserve() and unpreserve()
> callbacks. In that situation there is no way for the caller to protect
> itself against the outgoing FLB from being freed while it is using it.
> Incrementing the reference count in liveupdate_flb_get_outgoing()
> ensures it cannot be freed.
> 
> This change also aligns the outgoing FLB lifecycle management with the
> incoming FLB, since the latter uses the same get/put semantics.
> 
> Fixes: cab056f2aae7 ("liveupdate: luo_flb: introduce File-Lifecycle-Bound global state")
> Assisted-by: Gemini:gemini-3-pro-preview
> Signed-off-by: David Matlack <dmatlack@google.com>

Reviewed-by: Pasha Tatashin <pasha.tatashin@soleen.com> 

> ---
>  include/linux/liveupdate.h  |  5 +++++
>  kernel/liveupdate/luo_flb.c | 10 +++++++---
>  2 files changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/include/linux/liveupdate.h b/include/linux/liveupdate.h
> index 88722e5caf02..c344bf987b63 100644
> --- a/include/linux/liveupdate.h
> +++ b/include/linux/liveupdate.h
> @@ -243,6 +243,7 @@ int liveupdate_flb_get_incoming(struct liveupdate_flb *flb, void **objp);
>  void liveupdate_flb_put_incoming(struct liveupdate_flb *flb);
>  
>  int liveupdate_flb_get_outgoing(struct liveupdate_flb *flb, void **objp);
> +void liveupdate_flb_put_outgoing(struct liveupdate_flb *flb);
>  
>  #else /* CONFIG_LIVEUPDATE */
>  
> @@ -292,5 +293,9 @@ static inline int liveupdate_flb_get_outgoing(struct liveupdate_flb *flb,
>  	return -EOPNOTSUPP;
>  }
>  
> +static inline void liveupdate_flb_put_outgoing(struct liveupdate_flb *flb)
> +{
> +}
> +
>  #endif /* CONFIG_LIVEUPDATE */
>  #endif /* _LINUX_LIVEUPDATE_H */
> diff --git a/kernel/liveupdate/luo_flb.c b/kernel/liveupdate/luo_flb.c
> index 8f5c5dd01cd0..7ddef552ff6b 100644
> --- a/kernel/liveupdate/luo_flb.c
> +++ b/kernel/liveupdate/luo_flb.c
> @@ -135,7 +135,7 @@ static int luo_flb_file_preserve_one(struct liveupdate_flb *flb)
>  	return 0;
>  }
>  
> -static void luo_flb_file_unpreserve_one(struct liveupdate_flb *flb)
> +void liveupdate_flb_put_outgoing(struct liveupdate_flb *flb)
>  {
>  	struct luo_flb_private *private = luo_flb_get_private(flb);
>  
> @@ -266,7 +266,7 @@ int luo_flb_file_preserve(struct liveupdate_file_handler *fh)
>  
>  exit_err:
>  	list_for_each_entry_continue_reverse(iter, flb_list, list)
> -		luo_flb_file_unpreserve_one(iter->flb);
> +		liveupdate_flb_put_outgoing(iter->flb);
>  	up_read(&luo_register_rwlock);
>  
>  	return err;
> @@ -291,7 +291,7 @@ void luo_flb_file_unpreserve(struct liveupdate_file_handler *fh)
>  
>  	guard(rwsem_read)(&luo_register_rwlock);
>  	list_for_each_entry_reverse(iter, flb_list, list)
> -		luo_flb_file_unpreserve_one(iter->flb);
> +		liveupdate_flb_put_outgoing(iter->flb);
>  }
>  
>  /**
> @@ -546,6 +546,10 @@ int liveupdate_flb_get_outgoing(struct liveupdate_flb *flb, void **objp)
>  		return -EOPNOTSUPP;
>  
>  	guard(mutex)(&private->outgoing.lock);
> +	if (!private->outgoing.obj)
> +		return -ENOENT;
> +
> +	refcount_inc(&private->outgoing.count);
>  	*objp = private->outgoing.obj;
>  
>  	return 0;
> -- 
> 2.54.0.823.g6e5bcc1fc9-goog
> 

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 128793AD503
	for <linux-kernel@vger.kernel.org>; Thu,  4 Jun 2026 05:29:03 +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=1780550944; cv=none; b=c9IpunYZOA0HAB2C+nQegK+VBki1YXz9ip9aDDwxTGGpTYMzlpT3yInnAbdDCVoz8rYbKed0j+G4g6N9IdyUNjWE/qdousq7kezZHTpBIIe2owKqDJ6jLn1Vz9rmbaxQrorDM077qVkdeb2Lyqrwm+8TT3VQ076QjS+0ME5Apt4=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1780550944; c=relaxed/simple;
	bh=07E1qZrxKsL4Qx7RmYbV+QUhVLNqP5S5Boiy7USACpc=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	 Content-Type:Content-Disposition:In-Reply-To; b=FfOzc/9d6f0DvCsTW5RJkIJgYMQxN49RIKgQh56+aAkupRtpxAeAcQ8nVlIKx0Y6UCDAI4YeBGDE/ydaMIsUPmaRVCEHkURlsFOsMBF625THT21bA6AE9detPzSXNXVimfi5OS2unjD+KpbYCSLtHSkZuR0cZlYsKPIXhRGStc8=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Hi4u3/zv; 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="Hi4u3/zv"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8E49E1F00893;
	Thu,  4 Jun 2026 05:29:01 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org;
	s=k20260515; t=1780550943;
	bh=Os6BChiKMmQET3OKPbwcH6PuboYuxn41oT3xzkui4Vk=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To;
	b=Hi4u3/zv/smM5I0QakpRwwmSwlJ9Vjgpw74YmySQaUaiHmTdeQc2DbCL2hY0n3Y/B
	 xc5Ku6Tr45wthcdg007u+mQs9qUa6KWprYb/3VbAE3Kl+hCnI685uvOAtkMx3t6/W3
	 ta7PG3wR62pF9XQRdAfgglEQZunMoXcKw6mp7CDKZBeVCRBai7Hf/iPf45pZ9L9a69
	 QUJQUJ6K8oWCgBFAwBq+uW7N4NFMtB2ZzrKJlb+bFWWWmwZO67jGBKNtwiByrq4cBG
	 leE/m7HrjT5g4Lj8Q/BTtVA4TODa1ENbgJXgHiVe0PIYuLPDSeo14kCFoGpuBQDa6T
	 6ucu5rFt+5BGg==
Date: Thu, 4 Jun 2026 08:28:57 +0300
From: Mike Rapoport <rppt@kernel.org>
To: David Matlack <dmatlack@google.com>
Cc: kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Pasha Tatashin <pasha.tatashin@soleen.com>,
	Pratyush Yadav <pratyush@kernel.org>
Subject: Re: [PATCH 0/2] liveupdate: Small FLB fixes
Message-ID: <aiENGcp1UCq5XMme@kernel.org>
References: <20260528174140.1921129-1-dmatlack@google.com>
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20260528174140.1921129-1-dmatlack@google.com>

On Thu, May 28, 2026 at 05:41:38PM +0000, David Matlack wrote:
> This series has 2 small fixes to how FLBs are managed. First is to
> increase the outgoing FLB refcount during liveupdate_flb_get_outgoing()
> so it cannot be freed while the caller is using it, and to align with
> the semantics of liveupdate_flb_get_incoming(). The second is to prevent
> FLB retrieve() from being called multiple times if the first attempt
> fails.
> 
> Both of these changes are needed for the correctness of the PCI core
> support for Live Update:
> 
>   https://lore.kernel.org/linux-pci/20260522202410.3104264-1-dmatlack@google.com/

We are late in the release cycle and since there no in-tree flb users let's
postpone this after rc1.
 
> David Matlack (2):
>   liveupdate: Reference count outgoing FLB data
>   liveupdate: Remember FLB retrieve() status
> 
>  include/linux/liveupdate.h  | 11 +++++++++--
>  kernel/liveupdate/luo_flb.c | 20 ++++++++++++++------
>  2 files changed, 23 insertions(+), 8 deletions(-)
> 
> 
> base-commit: 5428435567cbe06c19914592fc22ca23c9ca1de5
> -- 
> 2.54.0.823.g6e5bcc1fc9-goog
> 

-- 
Sincerely yours,
Mike.

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 7FEB43F4821
	for <linux-kernel@vger.kernel.org>; Fri,  5 Jun 2026 13:09:30 +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=1780664975; cv=none; b=fln/Fb197CvGhS4UgT5ql60XspHrPoHAtTRVS/8QXNuzdFxcJtfXQ17ttuK4mJBEY4cUVY3swq1sPMpavZh4CIVG2DdXRhrWQ/dtFoCpBKyyl/xEzGgshqvfM479xT09DPU8uKmrmf3U1KcGcR7qTJ12jHub5kbrrdIiDzpTA6k=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1780664975; c=relaxed/simple;
	bh=+PIqhO62jrnvWmBNTdlZ4HsfwozuIah67+dLq4HYGlY=;
	h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID:
	 MIME-Version:Content-Type; b=SXELcl9Mfuyw/v3oOfXLubHUjEj29yfyrBnDpGwdfee1wntkkYKG6iuhPQvwmuXFFDCJVccbpfdg7H/FmSfhcZZUVqotsjqlNpbYKlYHMPR7CGt93xpL8qHF4DGIvPF1xs9cxCbKzXCLj4Vbpu90pjEhB+Q8UPx08b+flTHSeoA=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=lshDNLBh; 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="lshDNLBh"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id A8ED91F0089B;
	Fri,  5 Jun 2026 13:09:28 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org;
	s=k20260515; t=1780664969;
	bh=MSUGCFZbkdGQsRUVae3QaiSIyG10l/zFA2SJJnCDFTk=;
	h=From:To:Cc:Subject:In-Reply-To:References:Date;
	b=lshDNLBhgZQFNVje19VffYLe+ZFC9W8lZQs2f3s7kwfrG09Clru/mXdMIUrdWeUvV
	 kCiF9w2g8mOgl6ct8wSWE3zgj4Q2m0tSIaQLC5U8NmLNPDH0Q7owm1jdvRa0jTJaUd
	 hd1p1QmHyhHMXpXP8ZCT1YeChPdn555tDHPz/WzVbZZFQe7xK8RKyQ+TX2kov6EfBu
	 Pk6m0a2CX5c4t+rY/dkGc0irf8OEmopivtpCa5b/mUH9P5Be9vkwWDp3G8iHXiQXVq
	 /vOeGHmozLHEazZGAjZya4DT1m0ZRKC7GALyTNiOFlc2Qmc5jXMxJ2ZKUg143VBDTt
	 UXssIgzG71Qgg==
From: Pratyush Yadav <pratyush@kernel.org>
To: Mike Rapoport <rppt@kernel.org>
Cc: David Matlack <dmatlack@google.com>,  kexec@lists.infradead.org,
  linux-kernel@vger.kernel.org,  Andrew Morton <akpm@linux-foundation.org>,
  Pasha Tatashin <pasha.tatashin@soleen.com>,  Pratyush Yadav
 <pratyush@kernel.org>
Subject: Re: [PATCH 0/2] liveupdate: Small FLB fixes
In-Reply-To: <aiENGcp1UCq5XMme@kernel.org> (Mike Rapoport's message of "Thu, 4
	Jun 2026 08:28:57 +0300")
References: <20260528174140.1921129-1-dmatlack@google.com>
	<aiENGcp1UCq5XMme@kernel.org>
Date: Fri, 05 Jun 2026 15:09:27 +0200
Message-ID: <2vxzcxy5i16g.fsf@kernel.org>
User-Agent: Gnus/5.13 (Gnus v5.13)
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain

On Thu, Jun 04 2026, Mike Rapoport wrote:

> On Thu, May 28, 2026 at 05:41:38PM +0000, David Matlack wrote:
>> This series has 2 small fixes to how FLBs are managed. First is to
>> increase the outgoing FLB refcount during liveupdate_flb_get_outgoing()
>> so it cannot be freed while the caller is using it, and to align with
>> the semantics of liveupdate_flb_get_incoming(). The second is to prevent
>> FLB retrieve() from being called multiple times if the first attempt
>> fails.
>> 
>> Both of these changes are needed for the correctness of the PCI core
>> support for Live Update:
>> 
>>   https://lore.kernel.org/linux-pci/20260522202410.3104264-1-dmatlack@google.com/
>
> We are late in the release cycle and since there no in-tree flb users let's
> postpone this after rc1.

Yes, I agree.

[...]

-- 
Regards,
Pratyush Yadav

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 C1C62380FCB
	for <linux-kernel@vger.kernel.org>; Mon,  8 Jun 2026 14:19:14 +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=1780928355; cv=none; b=BmkRahbfpQGfhN/9FR7yFtyPZe764F6zRq0E29tpNO4GSosw0au/oRBjXxqd4hMcztiTSMBH4ZGnWYg9NMhYAylh4jIpJogKKNEyto6PvWXaaDlJ+qyLqC7VqnaGwCXIgngAijV5OsT5Uh0wzSnIQUb0h4zqxG+6lHzaqVg8/lc=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1780928355; c=relaxed/simple;
	bh=KxFEOhg7P516zZ7TBq8eyubT7XnYEh7Vf5m7Ce2kDlk=;
	h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID:
	 MIME-Version:Content-Type; b=nkAabVDcrFYXaljpZOoUmZogAjkl2ZKFnl9KAuMFueJc57sqtE7YDcTriLa+nqaoruZq8DCM1brJhyljL96+5MlbZuOjc1Ro2LDxlfo/9wVBuKFS3bA8m1VGfe/jfXQI8KBnkdrXB0N5e3Z3SteaC/Bwga0aA5oJjLVuIOReTRQ=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=OLD1qgx1; 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="OLD1qgx1"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 592671F00893;
	Mon,  8 Jun 2026 14:19:13 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org;
	s=k20260515; t=1780928354;
	bh=gtvAtyIWkgcGh5bt/21vAHxAw/x3unUhXw573vaCzPc=;
	h=From:To:Cc:Subject:In-Reply-To:References:Date;
	b=OLD1qgx1Q2ALx/ykbqbh/knGOvOBQnjApDdNeZJB8b/ezkWqap+NYtRL28TkoF4Gb
	 1rzfXZl7/bSff2jC9w5cHHfSythG4ByZ1aaIv5EBpq9w9g5qpsuL5/hIKF1mRO7L11
	 lgaSK3xDhJJ4+Y3EtjOsO0RZGVSMzd61OBjSVlZCT8WVg5fKHqF9n0+gfgti40KCsV
	 3R1zbLvvsJp5W6VQ60PfUnoMWGjgsCtB4gqk+Se2bL7BjB1LjECmWZH3K7wLr5oQfm
	 w+7j6qBuiIWmNa599w6HPx7wVtYEE+sBgaobJ+bzASqAecdaY9yul/2LxhSh4xhnRy
	 78L+TzX8YNGEw==
From: Pratyush Yadav <pratyush@kernel.org>
To: David Matlack <dmatlack@google.com>
Cc: Pratyush Yadav <pratyush@kernel.org>,  kexec@lists.infradead.org,
  linux-kernel@vger.kernel.org,  Andrew Morton <akpm@linux-foundation.org>,
  Mike Rapoport <rppt@kernel.org>,  Pasha Tatashin
 <pasha.tatashin@soleen.com>
Subject: Re: [PATCH 1/2] liveupdate: Reference count outgoing FLB data
In-Reply-To: <ah8SDsIuZQXyvpZq@google.com> (David Matlack's message of "Tue, 2
	Jun 2026 17:25:34 +0000")
References: <20260528174140.1921129-1-dmatlack@google.com>
	<20260528174140.1921129-2-dmatlack@google.com>
	<2vxzfr34dfty.fsf@kernel.org> <ah8SDsIuZQXyvpZq@google.com>
Date: Mon, 08 Jun 2026 16:19:12 +0200
Message-ID: <2vxzse6xt8rj.fsf@kernel.org>
User-Agent: Gnus/5.13 (Gnus v5.13)
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain

On Tue, Jun 02 2026, David Matlack wrote:

> On 2026-06-02 07:15 PM, Pratyush Yadav wrote:
>> Hi David,
>> 
>> On Thu, May 28 2026, David Matlack wrote:
>> 
>> > Increment the outgoing FLB refcount in liveupdate_flb_get_outgoing() so
>> > that the FLB structure cannot be freed while the caller is actively
>> > using it. Add an additional liveupdate_flb_put_outgoing() function so
>> > the caller can explicitly indicate when it is done using the outgoing
>> > FLB.
>> >
>> > During a Live Update, the kernel may need to fetch the outgoing FLB
>> > outside of the scope of a file handler's preserve() and unpreserve()
>> > callbacks. In that situation there is no way for the caller to protect
>> > itself against the outgoing FLB from being freed while it is using it.
>> > Incrementing the reference count in liveupdate_flb_get_outgoing()
>> > ensures it cannot be freed.
>> 
>> We grab a reference to the FLB's module when the first file using the
>> FLB is preserved. So the FLB should never go away while preserved files
>> exist. Once all preserved files go away, you normally shouldn't be doing
>> anything with the FLB anyway.
>> 
>> Can you please elaborate on the use case and why this is a problem?
>> Using the FLB outside of the standard LUO file callbacks sounds
>> problematic.
>
> The scenario I had in mind was to remove a PCI device from the outgoing
> FLB if the device is forcibly removed while the file is still preserved,
> for example someone writes 1 to /sys/bus/pci/devices/.../remove or a
> device is physically hot-unplugged.
>
> Specifically this call here from the patch below:
>
> +void pci_liveupdate_cleanup_device(struct pci_dev *dev)
> +{
> +	/*
> +	 * It should be safe to READ_ONCE() outside of the rwsem during cleanup
> +	 * since there should no longer be any references to @dev on the system.
> +	 */
> +	if (READ_ONCE(dev->liveupdate.outgoing)) {
> +		pci_WARN(dev, 1, "Destroying outgoing-preserved device!\n");
> +		pci_liveupdate_unpreserve(dev);
> +	}
> +}
>
> https://lore.kernel.org/linux-pci/20260522202410.3104264-3-dmatlack@google.com/
>
> I can do this without adding reference counting to
> liveupdate_flb_get_outgoing(), but the reference counting makes it
> obvious that the outgoing FLB will not be freed while I am using it
> here, and also aligns with liveupdate_flb_get_incoming().

The lifecycle of FLB is bound to _preserved_ files. So it is only valid
as long as preserved files exist. So I think you should only get the FLB
object when you are inside a file preservation callback for a file which
the FLB is registered. Anywhere outside of that, you are not guaranteed
to get anything sane.

This refcounting scheme breaks the inherent "file-lifecycle-bound" part
of FLB, since now anyone can grab a reference and hold the FLB as long
as they like, even when no preserved files exist.

For the normal case, your the VFIO driver gets probed, it registers its
file handler, then when the device is preserved by VFIO, the VFIO file
handler's callbacks can get the FLB and do whatever. LUO guarantees the
FLB exists. Anywhere outside of that, you should _not_ touch the FLB
because of the reasons above.

Now for hot-unplug, I think that case is not supported right now. When a
preserved file exists, LUO can only remove it when the user closes the
session. Trying to clean up the file from any other context will leave
dangling references to the file and we currently do not handle those.
Trying to hold the file reference won't help much either since LUO
callbacks will try to proceed as normal, and normal no longer applies.

For example, say userspace preserved the file for your device in their
session, then you hot-unplug the device, then userspace triggers a
kexec. What is the freeze() callback supposed to do? Sure, the FLB
object still exists, but the device doesn't. Similarly, if you force
remove the module, the freeze() callback itself no longer exists, and
you likely get a panic.

We might at some point support "invalidating" preserved files. I imagine
when you hot-unplug with a preserved device, you tell LUO to invalidate
all preserved files with that device. They would still exist in their
sessions, but all operations on them fail immediately, including
freeze(), which prevents live update from proceeding until user cleans
them up.

So unless I am missing something, I think this refcounting is a band-aid
and the real problem is to properly track these "invalidated" files.

Also, I think the refcounting on the incoming path is also a mistake.
Unfortunately for incoming, there is a need for accessing the FLB
outside of the file handling callbacks, since subsystems needs to use it
to initialize itself. But I suppose we can have a accessor that
subsystems can call once on boot/init to get their object. Then they use
it to initialize their state and refer to the state directly, with all
later calls going through the usual file handler callbacks.

If you are interested in solving this problem, we can have a chat to
talk in more detail, or perhaps have a discussion at one of the
bi-weeklies?

>
>> >
>> > This change also aligns the outgoing FLB lifecycle management with the
>> > incoming FLB, since the latter uses the same get/put semantics.
>> >
>> > Fixes: cab056f2aae7 ("liveupdate: luo_flb: introduce File-Lifecycle-Bound global state")
>> > Assisted-by: Gemini:gemini-3-pro-preview
>> > Signed-off-by: David Matlack <dmatlack@google.com>
>> [...]
>> 
>> -- 
>> Regards,
>> Pratyush Yadav

-- 
Regards,
Pratyush Yadav

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com [209.85.214.176])
	(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 1089E33F8DC
	for <linux-kernel@vger.kernel.org>; Mon,  8 Jun 2026 23:37:16 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.176
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1780961838; cv=none; b=IxRltIxZT/v7WfXUc1Fb71JHCk2FWIOwwcP6o2Ffxhn9Cxq+X4ianjbw/AbYCDY41w6xLGSRx0TurAB7Q81M4grBlSwyLm7f5E+0l9B54vJhVacaxN+9p9FuCwCF0+Z236QRVXAloeHm+jMmKX8bA1XYZ5S3oLP9QlYal6h/oC4=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1780961838; c=relaxed/simple;
	bh=DdM8CjuiXZU12OKpECTKcW4MnH6tcaYyclNnnN6UoAA=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	 Content-Type:Content-Disposition:In-Reply-To; b=H/jDT4w09b46Fk8D7XIXufLRky6aXmrBPeEvvWDneyoi2EPpsKWHU2Dhdh8Sx/fDw7D4d69x8ePkgu/3YB0I9EWMpXVX0u39Frb53/Y9u4PfswTBmnXJJmGiE68bW3Tr8AVFFakgoehxLDaoYYT5nhl7KT92g20kk16PsmJhxto=
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=exPJSJni; arc=none smtp.client-ip=209.85.214.176
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="exPJSJni"
Received: by mail-pl1-f176.google.com with SMTP id d9443c01a7336-2bf20f6be6bso37459015ad.3
        for <linux-kernel@vger.kernel.org>; Mon, 08 Jun 2026 16:37:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1780961836; x=1781566636; 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=DpzGpcAQ40PkxnKmTZfDAjxtQ+CCACqbEdWJNIRNZ7c=;
        b=exPJSJni8RfKCrUb6m+o1/u4SwofFgznw7sgRDNF6O+z5RegRA2reYb8U3mWF5nUdG
         QcwjS5Gv7o0ZDZhbjLFpbF+j+X1hGgbGkL8oB8IWtUe5OFP+dIJFUBydN/mI3KsB4SNf
         3VqLG9gpA2FGoL+kdlRkX0g0aWK7RsWmzwCETBgeitZRaujMpqgHmQVAO3GoKcGOwDpT
         +UFBt02BrrhqaAKyDlQ91da6WgsHWaEu7Bjwev+xFthshLipYaZj7/iYyt8pgSIwrxQS
         o40cYg3S8MAxsZ5gMwqfB4geYPAcXO1DjJglTPIuVQg8DPZ875TmsTLrgbs7OJWMtucq
         zFig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1780961836; x=1781566636;
        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=DpzGpcAQ40PkxnKmTZfDAjxtQ+CCACqbEdWJNIRNZ7c=;
        b=dkCLQVhnPew7zZO7RlGg5xc+4w5heRL5u4zbEUK5WeeRTZeYX+nuwzPUBU8goSHtbT
         VGigzpD5Rfwwqos/uD1tdZKpKjxQB+Ej8UE7wWv2a/928s2iF+Z79ygTNenrLfw7Olan
         AqDrZkTMeX1F6M1b1taVDn47MqA6K0P8MKuHDThl55bn9v1VhxSVOS3+JvJY5u6+qdZu
         bOqC7ECvv3ziPsYA9PYqxal901HxbO6Senar/bIDoeCIil02u4uqGpygd7ojzMyXylra
         3PXNy6VJv6wXp229cNK3T0ie1mzw0BTt3ePO7lhuxruZwsRPVKL5/MQoqCV7VhEhmBNx
         TMYQ==
X-Forwarded-Encrypted: i=1; AFNElJ+tGoBVtZFT58GIb6gekIWKkSTDA9WpxqglNgVLbstn5NE14ozb0mU4OMyFFD3cGNDy6bTQtmaq6b+EiLI=@vger.kernel.org
X-Gm-Message-State: AOJu0Yxy4DmRoPU5rFaPsbM9h4pWxKn5AjqJJgQgC+0a2U2MeSXy+wfU
	uyEVK3splkjJ6Nwli9Fw569elpAd3pyeXyEDotm2dOwZnRGGth+2JKg2/eFjPn6nBA==
X-Gm-Gg: Acq92OFUbvUjMAwxIxcsim0+FsNPP3+V8kq86bTb+Ip2+ba2EzOJCQycVhRECKtzCnz
	R3wfz5Q3nPhLsCmk7nXr0xZz2SC09gOOrOYfoj2kfIG769XlO84RaK95KBnHh/yeY7geJg9ULB8
	t4FsNkVUXQQWuJPlYU9y62N1fbvSpjOBLSTJjnGCID22McEt4Z5Tut2MNhW3ayL4yFaO6SD4xkb
	w11EVC6iQCkPxWKbBW8lax7nd6sqI2iRRFJpBuolbtDHS9OIwQxcFGZA5p6hicm37GcxzuaN+My
	ue/vsoHoJ7DsF08JOCnMIDaBaDQO5ylBDq2eN9qqfU0ZJojhQWsR6peg5t/YlbwZFkSd2l03mzn
	N0FyIp8tJogj4ieXD4Mr5Ck6ly5INYFpKV9NQ+x5bwaGG211ECUZ6no4CIVlCsnpkvUGkUOaeID
	5IopUmO+AKZRHruU6mFv9jlDpfd+3GDmYHqclvQl6wTvD8X85wVPKhk03Em/jJp3DvEyO4u5Uz
X-Received: by 2002:a17:902:da4b:b0:2c1:f262:494d with SMTP id d9443c01a7336-2c1f2624a70mr173213615ad.19.1780961835934;
        Mon, 08 Jun 2026 16:37:15 -0700 (PDT)
Received: from google.com (56.149.168.34.bc.googleusercontent.com. [34.168.149.56])
        by smtp.gmail.com with ESMTPSA id d9443c01a7336-2c164f9f358sm190982245ad.30.2026.06.08.16.37.15
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Mon, 08 Jun 2026 16:37:15 -0700 (PDT)
Date: Mon, 8 Jun 2026 23:37:12 +0000
From: David Matlack <dmatlack@google.com>
To: Pratyush Yadav <pratyush@kernel.org>
Cc: kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Mike Rapoport <rppt@kernel.org>,
	Pasha Tatashin <pasha.tatashin@soleen.com>
Subject: Re: [PATCH 1/2] liveupdate: Reference count outgoing FLB data
Message-ID: <aidSKOlkw_XMvVKl@google.com>
References: <20260528174140.1921129-1-dmatlack@google.com>
 <20260528174140.1921129-2-dmatlack@google.com>
 <2vxzfr34dfty.fsf@kernel.org>
 <ah8SDsIuZQXyvpZq@google.com>
 <2vxzse6xt8rj.fsf@kernel.org>
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2vxzse6xt8rj.fsf@kernel.org>

On 2026-06-08 04:19 PM, Pratyush Yadav wrote:
> On Tue, Jun 02 2026, David Matlack wrote:
> 
> > On 2026-06-02 07:15 PM, Pratyush Yadav wrote:
> >> Hi David,
> >> 
> >> On Thu, May 28 2026, David Matlack wrote:
> >> 
> >> > Increment the outgoing FLB refcount in liveupdate_flb_get_outgoing() so
> >> > that the FLB structure cannot be freed while the caller is actively
> >> > using it. Add an additional liveupdate_flb_put_outgoing() function so
> >> > the caller can explicitly indicate when it is done using the outgoing
> >> > FLB.
> >> >
> >> > During a Live Update, the kernel may need to fetch the outgoing FLB
> >> > outside of the scope of a file handler's preserve() and unpreserve()
> >> > callbacks. In that situation there is no way for the caller to protect
> >> > itself against the outgoing FLB from being freed while it is using it.
> >> > Incrementing the reference count in liveupdate_flb_get_outgoing()
> >> > ensures it cannot be freed.
> >> 
> >> We grab a reference to the FLB's module when the first file using the
> >> FLB is preserved. So the FLB should never go away while preserved files
> >> exist. Once all preserved files go away, you normally shouldn't be doing
> >> anything with the FLB anyway.
> >> 
> >> Can you please elaborate on the use case and why this is a problem?
> >> Using the FLB outside of the standard LUO file callbacks sounds
> >> problematic.
> >
> > The scenario I had in mind was to remove a PCI device from the outgoing
> > FLB if the device is forcibly removed while the file is still preserved,
> > for example someone writes 1 to /sys/bus/pci/devices/.../remove or a
> > device is physically hot-unplugged.
> >
> > Specifically this call here from the patch below:
> >
> > +void pci_liveupdate_cleanup_device(struct pci_dev *dev)
> > +{
> > +	/*
> > +	 * It should be safe to READ_ONCE() outside of the rwsem during cleanup
> > +	 * since there should no longer be any references to @dev on the system.
> > +	 */
> > +	if (READ_ONCE(dev->liveupdate.outgoing)) {
> > +		pci_WARN(dev, 1, "Destroying outgoing-preserved device!\n");
> > +		pci_liveupdate_unpreserve(dev);
> > +	}
> > +}
> >
> > https://lore.kernel.org/linux-pci/20260522202410.3104264-3-dmatlack@google.com/
> >
> > I can do this without adding reference counting to
> > liveupdate_flb_get_outgoing(), but the reference counting makes it
> > obvious that the outgoing FLB will not be freed while I am using it
> > here, and also aligns with liveupdate_flb_get_incoming().
> 
> The lifecycle of FLB is bound to _preserved_ files. So it is only valid
> as long as preserved files exist. So I think you should only get the FLB
> object when you are inside a file preservation callback for a file which
> the FLB is registered. Anywhere outside of that, you are not guaranteed
> to get anything sane.

LUO should enforce this then, IMO.

> This refcounting scheme breaks the inherent "file-lifecycle-bound" part
> of FLB, since now anyone can grab a reference and hold the FLB as long
> as they like, even when no preserved files exist.
> 
> For the normal case, your the VFIO driver gets probed, it registers its
> file handler, then when the device is preserved by VFIO, the VFIO file
> handler's callbacks can get the FLB and do whatever. LUO guarantees the
> FLB exists. Anywhere outside of that, you should _not_ touch the FLB
> because of the reasons above.
> 
> Now for hot-unplug, I think that case is not supported right now. When a
> preserved file exists, LUO can only remove it when the user closes the
> session. Trying to clean up the file from any other context will leave
> dangling references to the file and we currently do not handle those.
> Trying to hold the file reference won't help much either since LUO
> callbacks will try to proceed as normal, and normal no longer applies.
> 
> For example, say userspace preserved the file for your device in their
> session, then you hot-unplug the device, then userspace triggers a
> kexec. What is the freeze() callback supposed to do? Sure, the FLB
> object still exists, but the device doesn't. Similarly, if you force
> remove the module, the freeze() callback itself no longer exists, and
> you likely get a panic.
> 
> We might at some point support "invalidating" preserved files. I imagine
> when you hot-unplug with a preserved device, you tell LUO to invalidate
> all preserved files with that device. They would still exist in their
> sessions, but all operations on them fail immediately, including
> freeze(), which prevents live update from proceeding until user cleans
> them up.
> 
> So unless I am missing something, I think this refcounting is a band-aid
> and the real problem is to properly track these "invalidated" files.
> 
> Also, I think the refcounting on the incoming path is also a mistake.
> Unfortunately for incoming, there is a need for accessing the FLB
> outside of the file handling callbacks, since subsystems needs to use it
> to initialize itself. But I suppose we can have a accessor that
> subsystems can call once on boot/init to get their object. Then they use
> it to initialize their state and refer to the state directly, with all
> later calls going through the usual file handler callbacks.
> 
> If you are interested in solving this problem, we can have a chat to
> talk in more detail, or perhaps have a discussion at one of the
> bi-weeklies?

Thanks for the detailed reply but I think it's hard to discuss all these
as theoretical situations since we can get bogged down in the parts that
aren't clear yet and potential future use-cases.

Can you review the use of the outgoing and incoming FLB in the PCI core
series and let me know what you think I am doing wrong?

  https://lore.kernel.org/linux-pci/20260522202410.3104264-1-dmatlack@google.com/

> 
> >
> >> >
> >> > This change also aligns the outgoing FLB lifecycle management with the
> >> > incoming FLB, since the latter uses the same get/put semantics.
> >> >
> >> > Fixes: cab056f2aae7 ("liveupdate: luo_flb: introduce File-Lifecycle-Bound global state")
> >> > Assisted-by: Gemini:gemini-3-pro-preview
> >> > Signed-off-by: David Matlack <dmatlack@google.com>
> >> [...]
> >> 
> >> -- 
> >> Regards,
> >> Pratyush Yadav
> 
> -- 
> Regards,
> Pratyush Yadav

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail-qk1-f173.google.com (mail-qk1-f173.google.com [209.85.222.173])
	(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 10D543469E0
	for <linux-kernel@vger.kernel.org>; Tue,  9 Jun 2026 02:17:19 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.173
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1780971441; cv=none; b=shtIcY/ICqFNbr0FzCOWswdRhcep0ilYRlBvCbYdN0dBzX8rNwnDdSCegYRIOm1FP8MmUaeXgWYxwZ44MEPJc/hORzuyOXkUkO9dKno8Jf+RsrhIPUFaALDllW86Ke3FQ9F0TEoMt6qTOLRGjkAUI50Zs5oDIg8hNR1H62lk05w=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1780971441; c=relaxed/simple;
	bh=x4PXBmrW/AHe2aLmhxu4VW/p81MT02QNPgbB5vJdc1c=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	 Content-Type:Content-Disposition:In-Reply-To; b=ASEfzgMvLgaAj/DlVdI9yjtF4klMjijoyQcAe53wXiLVZ4phBRwIheAahWnmPQVSHxlY6up4cFX4hki3ueDgL3nIu9o+n+A6e0dh9UuqxYl+rfliKhkEDAP5Qc5pW4+ALfYmbiv5cB1Id7OOzkEQvi9PrbE7Jqunk5oG7BCb/do=
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=dG33dIT3; arc=none smtp.client-ip=209.85.222.173
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="dG33dIT3"
Received: by mail-qk1-f173.google.com with SMTP id af79cd13be357-9157b895c57so460955985a.3
        for <linux-kernel@vger.kernel.org>; Mon, 08 Jun 2026 19:17:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=soleen.com; s=google; t=1780971439; x=1781576239; 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=ylQEHysqMMp7KAoiMGAoFNU9p9TG2t3Mi/C9RjUsIj0=;
        b=dG33dIT3JLuNBDx21AMQpb3kepLEt0mkdYid93mbfbVd8hWplEw+jGKUz2ldz27Dxq
         1nwgDW15RyZtuWx022fwmDXG+W37EgrPj3oqrhuAH2ciyFbeAYF4RkZ76snZ6EdfuyBc
         zjnnbGjrG1M+Iux7oK8z66LUarts0NXV1xVhIv4Vq2zUs8klYnjGmKMq8KWSvUOwxn5e
         K7xKWzC33OA+qQdcvyMciEliy6tHqbJ8fPseTC0kKjBfQZybZmIID15J7erp6n6GRQCB
         m+3+Tnms1eVyVrn2syTWiNvsLrYEEQarpK+zh2bQsqzbIQWxiXkNbu0zyprry7SmYLM/
         +Ltw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1780971439; x=1781576239;
        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=ylQEHysqMMp7KAoiMGAoFNU9p9TG2t3Mi/C9RjUsIj0=;
        b=EwvXLhkQg2qmARGKLtTzI/RYANCDRANFaFUsVVFovJs+zORUydIPd6dWly0smibKax
         9A8Zsush4y8K0Yqj7qlmXTLBHWUS7hkYeeaL/vFZ+V9pwS8Cf7J4Efpvj/6xZelGNBGu
         A+vMQwwpUPvhziF8PE26QLEdPPUGWBR+LVCcC3ZJp7GYa3vqVfSmIRIu6E1uxBDHsx2L
         D8x5UCwlJHc/oapHZUUiMkXuePC5qQ0dYyY2RhUaAXkoX044ZhrNACVmxf29K29sKiIo
         6Jlq2y1yaDh6YD5eq7+dqXi2E++Ivwc+nr9nyhV42LsNlRwg8KWUfnlLaN07W4vtypBV
         AsBA==
X-Forwarded-Encrypted: i=1; AFNElJ9tMB2fUr+qJU/WuiSxgpwTRPvCDWXhfrevhsDRTGyugoP2mDui1fyQ6nJ0en7OMYoXblIT17SFNJQhMRU=@vger.kernel.org
X-Gm-Message-State: AOJu0YyvBPaVXhPRqy/R81wTFYT5iecf5eC3/eLvqb7z/WdQ/apCgkhi
	0el519QbI1l5RaWhF5P8IrCOvGmUDM2fSaM7Ui24E0p3pvWxDX4lgaUeQKORQ36S9tE=
X-Gm-Gg: Acq92OETGXFXC/qM2ayIoevaAIycISjVqSKEjjST2JDJM4fVTFPK4ZLZMi8fCmYgG22
	u9zRD2hYJk+hgbpe0JT8raJgFyaPMBAzFanYkiOTZ37gzJZ51sRV21NzLe24jOUr9bDeLaGk7BU
	vRXEEeBazKlNDzKfKndnRMaHIFmVah0Z8vbdjxti72b3yYrEx/Z3mZ6pbZ2juBxZDwABTcUiPxn
	qTtqGMAwvi3my/FX4HEMUy9SsUw4zb6Dm/AXWfZDk5oLgT4+7vb5vbdOMtu3zeWdIZd7n9rUDZP
	kYQPG65m2kZBOdxiXVd1pcRlr0UJBvzYBkVe045vE4h7QZLN19oAAwnOIPaae51+v96k+JCF9we
	76nN56tGsH/KFsAV7cDwKQMeTNneiTbHmmMODt4BAaDdFXMLK8qwyBckckF0r7WWvON8l990Tnf
	VNeRB9n8XrHhk2E2kB5+omosw2UD1nIryXDz+T8zAQ5DsUGmZYKnjaqUHzZnKL/bzQW+u8Dcc2
X-Received: by 2002:a05:620a:1983:b0:914:bf8a:ba81 with SMTP id af79cd13be357-915a9cf8543mr2830607485a.27.1780971438749;
        Mon, 08 Jun 2026 19:17:18 -0700 (PDT)
Received: from plex ([71.181.43.54])
        by smtp.gmail.com with ESMTPSA id af79cd13be357-9158a37c50bsm1974387085a.24.2026.06.08.19.17.17
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Mon, 08 Jun 2026 19:17:18 -0700 (PDT)
Date: Tue, 9 Jun 2026 02:17:17 +0000
From: Pasha Tatashin <pasha.tatashin@soleen.com>
To: David Matlack <dmatlack@google.com>
Cc: Pratyush Yadav <pratyush@kernel.org>, kexec@lists.infradead.org, 
	linux-kernel@vger.kernel.org, Andrew Morton <akpm@linux-foundation.org>, 
	Mike Rapoport <rppt@kernel.org>, Pasha Tatashin <pasha.tatashin@soleen.com>
Subject: Re: [PATCH 1/2] liveupdate: Reference count outgoing FLB data
Message-ID: <aidpNcyBcee0HMCE@plex>
References: <20260528174140.1921129-1-dmatlack@google.com>
 <20260528174140.1921129-2-dmatlack@google.com>
 <2vxzfr34dfty.fsf@kernel.org>
 <ah8SDsIuZQXyvpZq@google.com>
 <2vxzse6xt8rj.fsf@kernel.org>
 <aidSKOlkw_XMvVKl@google.com>
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <aidSKOlkw_XMvVKl@google.com>

On 06-08 23:37, David Matlack wrote:
> On 2026-06-08 04:19 PM, Pratyush Yadav wrote:
> > On Tue, Jun 02 2026, David Matlack wrote:
> > 
> > > On 2026-06-02 07:15 PM, Pratyush Yadav wrote:
> > >> Hi David,
> > >> 
> > >> On Thu, May 28 2026, David Matlack wrote:
> > >> 
> > >> > Increment the outgoing FLB refcount in liveupdate_flb_get_outgoing() so
> > >> > that the FLB structure cannot be freed while the caller is actively
> > >> > using it. Add an additional liveupdate_flb_put_outgoing() function so
> > >> > the caller can explicitly indicate when it is done using the outgoing
> > >> > FLB.
> > >> >
> > >> > During a Live Update, the kernel may need to fetch the outgoing FLB
> > >> > outside of the scope of a file handler's preserve() and unpreserve()
> > >> > callbacks. In that situation there is no way for the caller to protect
> > >> > itself against the outgoing FLB from being freed while it is using it.
> > >> > Incrementing the reference count in liveupdate_flb_get_outgoing()
> > >> > ensures it cannot be freed.
> > >> 
> > >> We grab a reference to the FLB's module when the first file using the
> > >> FLB is preserved. So the FLB should never go away while preserved files
> > >> exist. Once all preserved files go away, you normally shouldn't be doing
> > >> anything with the FLB anyway.
> > >> 
> > >> Can you please elaborate on the use case and why this is a problem?
> > >> Using the FLB outside of the standard LUO file callbacks sounds
> > >> problematic.
> > >
> > > The scenario I had in mind was to remove a PCI device from the outgoing
> > > FLB if the device is forcibly removed while the file is still preserved,
> > > for example someone writes 1 to /sys/bus/pci/devices/.../remove or a
> > > device is physically hot-unplugged.
> > >
> > > Specifically this call here from the patch below:
> > >
> > > +void pci_liveupdate_cleanup_device(struct pci_dev *dev)
> > > +{
> > > +	/*
> > > +	 * It should be safe to READ_ONCE() outside of the rwsem during cleanup
> > > +	 * since there should no longer be any references to @dev on the system.
> > > +	 */
> > > +	if (READ_ONCE(dev->liveupdate.outgoing)) {
> > > +		pci_WARN(dev, 1, "Destroying outgoing-preserved device!\n");
> > > +		pci_liveupdate_unpreserve(dev);
> > > +	}
> > > +}
> > >
> > > https://lore.kernel.org/linux-pci/20260522202410.3104264-3-dmatlack@google.com/
> > >
> > > I can do this without adding reference counting to
> > > liveupdate_flb_get_outgoing(), but the reference counting makes it
> > > obvious that the outgoing FLB will not be freed while I am using it
> > > here, and also aligns with liveupdate_flb_get_incoming().
> > 
> > The lifecycle of FLB is bound to _preserved_ files. So it is only valid

An FLB is a shared global resource whose lifecycle is bound to the 
duration of first creation and final destruction across multiple files. 
It is not associated with any single preserved file, but rather with the 
fact that files of a particular type(s) are currently being preserved.

Because the kernel is highly asynchronous, we must handle concurrent 
access and race conditions during teardown and FLB lookups. Reference 
counting provides a standard, robust, and methodical way to handle this 
safely.

> > as long as preserved files exist. So I think you should only get the FLB
> > object when you are inside a file preservation callback for a file which

Limiting access to only within a file preservation callback is not 
feasible. FLBs are global resources and may be queried early during boot 
or late during teardown, completely outside of a specific file's 
preservation callback.

> > the FLB is registered. Anywhere outside of that, you are not guaranteed
> > to get anything sane.
> 
> LUO should enforce this then, IMO.
> 
> > This refcounting scheme breaks the inherent "file-lifecycle-bound" part
> > of FLB, since now anyone can grab a reference and hold the FLB as long
> > as they like, even when no preserved files exist.

This is the standard design pattern for shared resources in the kernel. 
When the last file of that type is unpreserved, the FLB's reference 
count reaches zero, and it is cleanly destroyed.

If there is a bug where someone holds onto a reference indefinitely, 
that is simply a leak/bug to be fixed. It is not a flaw in the 
reference-counting pattern itself, which is crucial for preventing 
use-after-free and race conditions under concurrent access.

> > For the normal case, your the VFIO driver gets probed, it registers its
> > file handler, then when the device is preserved by VFIO, the VFIO file
> > handler's callbacks can get the FLB and do whatever. LUO guarantees the
> > FLB exists. Anywhere outside of that, you should _not_ touch the FLB
> > because of the reasons above.
> > 
> > Now for hot-unplug, I think that case is not supported right now. When a
> > preserved file exists, LUO can only remove it when the user closes the
> > session. Trying to clean up the file from any other context will leave
> > dangling references to the file and we currently do not handle those.
> > Trying to hold the file reference won't help much either since LUO
> > callbacks will try to proceed as normal, and normal no longer applies.
> > 
> > For example, say userspace preserved the file for your device in their
> > session, then you hot-unplug the device, then userspace triggers a
> > kexec. What is the freeze() callback supposed to do? Sure, the FLB
> > object still exists, but the device doesn't. Similarly, if you force
> > remove the module, the freeze() callback itself no longer exists, and
> > you likely get a panic.
> > 
> > We might at some point support "invalidating" preserved files. I imagine
> > when you hot-unplug with a preserved device, you tell LUO to invalidate
> > all preserved files with that device. They would still exist in their
> > sessions, but all operations on them fail immediately, including
> > freeze(), which prevents live update from proceeding until user cleans
> > them up.
> > 
> > So unless I am missing something, I think this refcounting is a band-aid
> > and the real problem is to properly track these "invalidated" files.
> > 
> > Also, I think the refcounting on the incoming path is also a mistake.

On incoming path FLBs may be accessed during early boot and later 
including once we enter userspace. We must have a way to ensure valid, 
race-free access to these shared resources. Without reference counting, 
querying the existence of an FLB or retrieving it would require 
introducing global locking, which is highly undesirable.

Also, having both the incoming and outgoing FLB paths behave 
symmetrically using the same reference-counting API makes the overall 
design uniform, clean, and less error-prone.

> > Unfortunately for incoming, there is a need for accessing the FLB
> > outside of the file handling callbacks, since subsystems needs to use it
> > to initialize itself. But I suppose we can have a accessor that
> > subsystems can call once on boot/init to get their object. Then they use
> > it to initialize their state and refer to the state directly, with all
> > later calls going through the usual file handler callbacks.
> > 
> > If you are interested in solving this problem, we can have a chat to
> > talk in more detail, or perhaps have a discussion at one of the
> > bi-weeklies?
> 
> Thanks for the detailed reply but I think it's hard to discuss all these
> as theoretical situations since we can get bogged down in the parts that
> aren't clear yet and potential future use-cases.
> 
> Can you review the use of the outgoing and incoming FLB in the PCI core
> series and let me know what you think I am doing wrong?
> 
>   https://lore.kernel.org/linux-pci/20260522202410.3104264-1-dmatlack@google.com/
> 
> > 
> > >
> > >> >
> > >> > This change also aligns the outgoing FLB lifecycle management with the
> > >> > incoming FLB, since the latter uses the same get/put semantics.
> > >> >
> > >> > Fixes: cab056f2aae7 ("liveupdate: luo_flb: introduce File-Lifecycle-Bound global state")
> > >> > Assisted-by: Gemini:gemini-3-pro-preview
> > >> > Signed-off-by: David Matlack <dmatlack@google.com>
> > >> [...]
> > >> 
> > >> -- 
> > >> Regards,
> > >> Pratyush Yadav
> > 
> > -- 
> > Regards,
> > Pratyush Yadav

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 57F442DC357
	for <linux-kernel@vger.kernel.org>; Tue,  9 Jun 2026 13:33:13 +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=1781011995; cv=none; b=jGD6Lb6JfdEqZb6Qx6g0pqthFzrVjHMngBRC8VlSbC3W5WRScb6kEZYzohnFG85VKGGDSGQtCihbY/aGph5tNYJA7sYajXOu90aL+kmI0ExZ+/jjT0N3Uaw9b4+l6OiCxoCh8Rz0T8VrFvSxigNXpiWXDtPwSuc3hqZU9UXFGAc=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1781011995; c=relaxed/simple;
	bh=v7ZY4u3PEHHmPXLoYhHhO4STRQJq6jrVZNJoB90FpMU=;
	h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID:
	 MIME-Version:Content-Type; b=uCtB9EHrgKdH4LquOE2+gPrtFR5SO6b6d+ggYvWlgHw7v5iMj75ifHPlhiw4MnRLU8g82KkM9wxEncEJ5ZLAt0nYiBOs5rW45AcETao7egj7jmnNJ0y1814Nu5f3vatOh2Zxih8ve3yckx/ByEIreAuyY57vnXnG/0SMxMtr5P0=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=a4lVSRIY; 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="a4lVSRIY"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id A74BD1F00893;
	Tue,  9 Jun 2026 13:33:11 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org;
	s=k20260515; t=1781011993;
	bh=mPyYTg0OHT/1olm05SvzdJMzrmZ5+gyo8bDaCSODScQ=;
	h=From:To:Cc:Subject:In-Reply-To:References:Date;
	b=a4lVSRIYOxSxERDL4P+xqbgfRFotgdtbU08mBzO4YA/mrhUUq73RAlWh3+51j2hEi
	 9bxBRrFzcTRskjy8S7U11Ft2ctVHoKYhFJqs3sPnejuuxO4q+My92/tNd1gqjbgyJM
	 PQNWbsSMeSfv4N/6tpBnTtCT1/3tJczEcJhY1bUiXt5vTtIhKJFbdaBnvUXLjSlmB/
	 zGcRhvKh5I1ljLVk+A2ztHNEy7nKLilijsJ7XNAQLXT2rqYbZR6W36c1ZXSittdHzB
	 R3eEnC9vmAL8v0k1VoSkeTizLhK5O1GqL+rudCiCi1rxVaWj1bBAi/v5DTiDYEZgNi
	 wlrP2Y9LQTAGw==
From: Pratyush Yadav <pratyush@kernel.org>
To: Pasha Tatashin <pasha.tatashin@soleen.com>
Cc: David Matlack <dmatlack@google.com>,  Pratyush Yadav
 <pratyush@kernel.org>,  kexec@lists.infradead.org,
  linux-kernel@vger.kernel.org,  Andrew Morton <akpm@linux-foundation.org>,
  Mike Rapoport <rppt@kernel.org>
Subject: Re: [PATCH 1/2] liveupdate: Reference count outgoing FLB data
In-Reply-To: <aidpNcyBcee0HMCE@plex> (Pasha Tatashin's message of "Tue, 9 Jun
	2026 02:17:17 +0000")
References: <20260528174140.1921129-1-dmatlack@google.com>
	<20260528174140.1921129-2-dmatlack@google.com>
	<2vxzfr34dfty.fsf@kernel.org> <ah8SDsIuZQXyvpZq@google.com>
	<2vxzse6xt8rj.fsf@kernel.org> <aidSKOlkw_XMvVKl@google.com>
	<aidpNcyBcee0HMCE@plex>
Date: Tue, 09 Jun 2026 15:33:10 +0200
Message-ID: <2vxzv7brsusp.fsf@kernel.org>
User-Agent: Gnus/5.13 (Gnus v5.13)
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain

On Tue, Jun 09 2026, Pasha Tatashin wrote:

> On 06-08 23:37, David Matlack wrote:
>> On 2026-06-08 04:19 PM, Pratyush Yadav wrote:
>> > On Tue, Jun 02 2026, David Matlack wrote:
>> > 
>> > > On 2026-06-02 07:15 PM, Pratyush Yadav wrote:
>> > >> Hi David,
>> > >> 
>> > >> On Thu, May 28 2026, David Matlack wrote:
>> > >> 
>> > >> > Increment the outgoing FLB refcount in liveupdate_flb_get_outgoing() so
>> > >> > that the FLB structure cannot be freed while the caller is actively
>> > >> > using it. Add an additional liveupdate_flb_put_outgoing() function so
>> > >> > the caller can explicitly indicate when it is done using the outgoing
>> > >> > FLB.
>> > >> >
>> > >> > During a Live Update, the kernel may need to fetch the outgoing FLB
>> > >> > outside of the scope of a file handler's preserve() and unpreserve()
>> > >> > callbacks. In that situation there is no way for the caller to protect
>> > >> > itself against the outgoing FLB from being freed while it is using it.
>> > >> > Incrementing the reference count in liveupdate_flb_get_outgoing()
>> > >> > ensures it cannot be freed.
>> > >> 
>> > >> We grab a reference to the FLB's module when the first file using the
>> > >> FLB is preserved. So the FLB should never go away while preserved files
>> > >> exist. Once all preserved files go away, you normally shouldn't be doing
>> > >> anything with the FLB anyway.
>> > >> 
>> > >> Can you please elaborate on the use case and why this is a problem?
>> > >> Using the FLB outside of the standard LUO file callbacks sounds
>> > >> problematic.
>> > >
>> > > The scenario I had in mind was to remove a PCI device from the outgoing
>> > > FLB if the device is forcibly removed while the file is still preserved,
>> > > for example someone writes 1 to /sys/bus/pci/devices/.../remove or a
>> > > device is physically hot-unplugged.
>> > >
>> > > Specifically this call here from the patch below:
>> > >
>> > > +void pci_liveupdate_cleanup_device(struct pci_dev *dev)
>> > > +{
>> > > +	/*
>> > > +	 * It should be safe to READ_ONCE() outside of the rwsem during cleanup
>> > > +	 * since there should no longer be any references to @dev on the system.
>> > > +	 */
>> > > +	if (READ_ONCE(dev->liveupdate.outgoing)) {
>> > > +		pci_WARN(dev, 1, "Destroying outgoing-preserved device!\n");
>> > > +		pci_liveupdate_unpreserve(dev);
>> > > +	}
>> > > +}
>> > >
>> > > https://lore.kernel.org/linux-pci/20260522202410.3104264-3-dmatlack@google.com/
>> > >
>> > > I can do this without adding reference counting to
>> > > liveupdate_flb_get_outgoing(), but the reference counting makes it
>> > > obvious that the outgoing FLB will not be freed while I am using it
>> > > here, and also aligns with liveupdate_flb_get_incoming().
>> > 
>> > The lifecycle of FLB is bound to _preserved_ files. So it is only valid
>
> An FLB is a shared global resource whose lifecycle is bound to the 
> duration of first creation and final destruction across multiple files. 
> It is not associated with any single preserved file, but rather with the 
> fact that files of a particular type(s) are currently being preserved.
>
> Because the kernel is highly asynchronous, we must handle concurrent 
> access and race conditions during teardown and FLB lookups. Reference 
> counting provides a standard, robust, and methodical way to handle this 
> safely.

But that's my point. As you say, destruction is supposed to happen when
the last file using the FLB goes away. That stops being true when any
random caller can hold a reference. So now you can get a FLB with no
files. It fundamentally breaks the model we started with FLBs.

The FLB model also deals with asynchronicity, but it does so by managing
the lifetime of the FLB directly in LUO instead of leaving it to
subsystems. This reduces cognitive load on the users of the FLB API.
They do not need to care about managing the lifecycle themselves.

If users of FLB are directly managing references, then why does LUO even
need to manage anything? Then subsystems can just create their own
global data structure, grab a reference and release it as they please.
That is a perfectly valid way of managing this global object, but we
decided to _not_ do this because letting LUO manage the lifecycle (and
thus the refcount) results in code that is easier to understand and
reason about.

>
>> > as long as preserved files exist. So I think you should only get the FLB
>> > object when you are inside a file preservation callback for a file which
>
> Limiting access to only within a file preservation callback is not 
> feasible. FLBs are global resources and may be queried early during boot 
> or late during teardown, completely outside of a specific file's 
> preservation callback.

To clarify, I don't mean only the preservation callback. I mean during
any of the file handler callbacks.

And if the subsystem needs to do something with the FLB after all its
files are frozen, we can provide a freeze() callback to
liveupdate_flb_ops.

Why do you need to access the FLB anywhere else outside of these
callbacks? What's the use case?

>
>> > the FLB is registered. Anywhere outside of that, you are not guaranteed
>> > to get anything sane.
>> 
>> LUO should enforce this then, IMO.
>> 
>> > This refcounting scheme breaks the inherent "file-lifecycle-bound" part
>> > of FLB, since now anyone can grab a reference and hold the FLB as long
>> > as they like, even when no preserved files exist.
>
> This is the standard design pattern for shared resources in the kernel. 
> When the last file of that type is unpreserved, the FLB's reference 
> count reaches zero, and it is cleanly destroyed.
>
> If there is a bug where someone holds onto a reference indefinitely, 
> that is simply a leak/bug to be fixed. It is not a flaw in the 
> reference-counting pattern itself, which is crucial for preventing 
> use-after-free and race conditions under concurrent access.

Going to my previous point, the whole reason for FLB to exist is that we
don't want to burden subsystems with managing these references. If we do
that, then I think it would be way easier to just get rid of FLBs
entirely. It would be almost as easy for each subsystem to allocate a
global struct with its state and a refcount.

I don't get why we want to mix these approaches. FLB makes my life as a
user of the API easier because I don't need to worry about the
lifetimes. LUO takes care of that for me.

>
>> > For the normal case, your the VFIO driver gets probed, it registers its
>> > file handler, then when the device is preserved by VFIO, the VFIO file
>> > handler's callbacks can get the FLB and do whatever. LUO guarantees the
>> > FLB exists. Anywhere outside of that, you should _not_ touch the FLB
>> > because of the reasons above.
>> > 
>> > Now for hot-unplug, I think that case is not supported right now. When a
>> > preserved file exists, LUO can only remove it when the user closes the
>> > session. Trying to clean up the file from any other context will leave
>> > dangling references to the file and we currently do not handle those.
>> > Trying to hold the file reference won't help much either since LUO
>> > callbacks will try to proceed as normal, and normal no longer applies.
>> > 
>> > For example, say userspace preserved the file for your device in their
>> > session, then you hot-unplug the device, then userspace triggers a
>> > kexec. What is the freeze() callback supposed to do? Sure, the FLB
>> > object still exists, but the device doesn't. Similarly, if you force
>> > remove the module, the freeze() callback itself no longer exists, and
>> > you likely get a panic.
>> > 
>> > We might at some point support "invalidating" preserved files. I imagine
>> > when you hot-unplug with a preserved device, you tell LUO to invalidate
>> > all preserved files with that device. They would still exist in their
>> > sessions, but all operations on them fail immediately, including
>> > freeze(), which prevents live update from proceeding until user cleans
>> > them up.
>> > 
>> > So unless I am missing something, I think this refcounting is a band-aid
>> > and the real problem is to properly track these "invalidated" files.
>> > 
>> > Also, I think the refcounting on the incoming path is also a mistake.
>
> On incoming path FLBs may be accessed during early boot and later 
> including once we enter userspace. We must have a way to ensure valid, 
> race-free access to these shared resources. Without reference counting, 
> querying the existence of an FLB or retrieving it would require 
> introducing global locking, which is highly undesirable.

Ideally, on the incoming path LUO should provide a subsystem init hook
that lets them get their FLB data and use it during init. Unfortunately
it isn't easy because of boot ordering. You might need the FLB before
LUO comes up.

But I think we should still tighten up access to the FLB on the incoming
side as well. You can use the FLB early until it gets registered (or
something similar) with LUO. Then you hand over the ownership to LUO and
can only use it from the standard LUO callbacks. At this point the
access model of incoming and outgoing become the same.

Overall, my point is that we should pick one usage model. Either LUO
manages the lifetime of the object or the subsystem. Mixing both this
way sounds wrong.

>
> Also, having both the incoming and outgoing FLB paths behave 
> symmetrically using the same reference-counting API makes the overall 
> design uniform, clean, and less error-prone.
>
>> > Unfortunately for incoming, there is a need for accessing the FLB
>> > outside of the file handling callbacks, since subsystems needs to use it
>> > to initialize itself. But I suppose we can have a accessor that
>> > subsystems can call once on boot/init to get their object. Then they use
>> > it to initialize their state and refer to the state directly, with all
>> > later calls going through the usual file handler callbacks.
>> > 
>> > If you are interested in solving this problem, we can have a chat to
>> > talk in more detail, or perhaps have a discussion at one of the
>> > bi-weeklies?
>> 
>> Thanks for the detailed reply but I think it's hard to discuss all these
>> as theoretical situations since we can get bogged down in the parts that
>> aren't clear yet and potential future use-cases.
>> 
>> Can you review the use of the outgoing and incoming FLB in the PCI core
>> series and let me know what you think I am doing wrong?
>> 
>>   https://lore.kernel.org/linux-pci/20260522202410.3104264-1-dmatlack@google.com/

Yes, good idea. Will do.

-- 
Regards,
Pratyush Yadav

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail-pg1-f179.google.com (mail-pg1-f179.google.com [209.85.215.179])
	(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 A1E9E3E0730
	for <linux-kernel@vger.kernel.org>; Thu,  9 Jul 2026 20:52:08 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=209.85.215.179
ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1783630330; cv=pass; b=Fid4oKJZTsqEFKOmG4Y0Dp+S6qNDDp88KQMFWX1HletcB2EIzxt37RHkDQAAE4h5cygjGggUakcbuPxzWzbgNfuHtQgpDfMWQBHFBM747LE8ERjpzGeKHrfmAAO3s/tB8ZVKBa1H5/hFFiCaoTpyNyeJLPA7h9E7LkaYJ8WQZN4=
ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1783630330; c=relaxed/simple;
	bh=ri9EDBEbQBNL1T83GHYB/By4dlUeiWdRQj0jLSTU9Lg=;
	h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:
	 To:Cc:Content-Type; b=rHoWNAXMO8N6mp8Ll9qTqBG2hIREGJkYA/4V67nanWKJUrmLBVYIzDgVCZG4ilggaOk3mKp0sFok8YQlkA+Q+otdPTpj4SzbsVymLr97Iuu6zFyxpseL1+I1JWLDv0BE4+kbDVoCGkR2zEAmaAlVJkKHeIXzpdWQNErj9IX/dkM=
ARC-Authentication-Results:i=2; 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=Zt+Ulw11; arc=pass smtp.client-ip=209.85.215.179
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="Zt+Ulw11"
Received: by mail-pg1-f179.google.com with SMTP id 41be03b00d2f7-c96b08cdd1cso191207a12.0
        for <linux-kernel@vger.kernel.org>; Thu, 09 Jul 2026 13:52:08 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1783630328; cv=none;
        d=google.com; s=arc-20260327;
        b=iPJhFmrN6On8vm+fqXXZHH/aQ5CmALv/I76s1AMeWR01n9c21Ji6nqwiSsUdNveCUk
         z+K1A0yh9ebPuB6Ll5DhX6F97nBk8kt49TnzWCx+Uw6YnSmUDABKwjMHFukXtZEuDwPn
         Kxy9CH4xiHWMCD/VsC/HmB1UOmVKJTpht0KGa/t5S/RIBWgtdzYAb5PpSgXBRHQpIFfm
         PdIb3XPuJ4HnYO8Cdejl8h5S5qw/xb5A1M6mOhsU7PgjbsjOGYIQ7x5nngNNRxzHb5uL
         n9fU2EdRlqtKuAjoE8bcZazcE3SGux4GFwDrwuJT2epXQ0Dr53cIl1OxhMMx9XDsmWi+
         3yOw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:dkim-signature;
        bh=wwR3+tAmZvna5GpBM6IknnMly0341sDm9GPfoI+7yn8=;
        fh=xNbuoXxXTgT35VOX1h/od2h4assBsRN2IkQXUDaZtmo=;
        b=WLjlbvLa/1PNc6s3UVykYsqfcnhYb7i0gnzsS5SMlxnjMwepT8I0GZsykSfSDh4WMf
         vCSQ+Qo3ak4NoufrSTBJHfoH92IBkyKxm4xkey+lG5Sgc7wKVP6YijuzTxpmcd2e/N3M
         OBAgGrrweTro1jOprSYukR85YAhkJD7pJWdDWA0a4+kVWvX51lXMeC/mWXT8n8DTbGu/
         6IqAbuHRu5zRNghudo+ZZWeuXt7YeKxs3YcqbzgH+YIVpz4MCCqvfkrSaSknt1BLOlPh
         7mM46pE0BItQuU9Bh/h6xMG4+/QsQsZdzgueVYlTOJpkpjoeGhydzhvnWMQOX4Cy4BSA
         MiUw==;
        darn=vger.kernel.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1783630328; x=1784235128; darn=vger.kernel.org;
        h=content-transfer-encoding:content-type:cc:to:subject:message-id
         :date:from:in-reply-to:references:mime-version:from:to:cc:subject
         :date:message-id:reply-to:content-type;
        bh=wwR3+tAmZvna5GpBM6IknnMly0341sDm9GPfoI+7yn8=;
        b=Zt+Ulw11VlIIRJUtfvpnM4VyEYBk/eKSCgcz+rV20QXFN4mLvvqpRac/vK10JBSE7Q
         evRWL/6+K0St9rxzH69TOs1e/3sUjIr8ni+aoHca5xQrTy1ufi0miHncwphq+CESOi3F
         ZMb6H0bY9Bh+tkHaUfQGHy1rFogYb473pxjyd1wVEjoQYNamYV5fWmlfKc9hJIBunuhn
         yX4V7saSrW3bt37G/XiCjRJY371uhu8bZJ5U3aFovMUNTmmcLUT8RlbmrFlXkn6drdvf
         pb7+URxal2fwAeYH3budbLVeFrDZOHZA2brtfXHFnFtqbZ8Zb/ekiRg0DoFXRmo/ORLl
         6bHQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1783630328; x=1784235128;
        h=content-transfer-encoding:content-type:cc:to:subject:message-id
         :date:from:in-reply-to:references:mime-version:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=wwR3+tAmZvna5GpBM6IknnMly0341sDm9GPfoI+7yn8=;
        b=gYzaOpSrAGPrYqoMJaxQwfTcE4SQ4JHkLf3hHT9x27SCHJa8RTeYfCM91ESLHXAvpG
         rHUesXFD+8EGXLPhUKuL+6zGZcawSge3M81bGdt9iRGXTfH8e36DMtNcmy9A3wSN2SBG
         FzyabNsfUkRUk7ApIHbwzkwleE2NWD1sDe7KP0a5WzTTrLTOOxPa3bWOC0trtztj/5Zl
         o57vYHSA1S1Y3Pyf3naRt6MfDrwURQF61ErEWhDE0NlNqLbCBxsNP9tMYytnr6Ymgel5
         yljmrXVwLB4nTwjnw8ZgpDt0xuH+PqOR+M3H6Cjo3ikESJSWPo+TufVlDX7a6+Y2Lqgw
         6cQw==
X-Forwarded-Encrypted: i=1; AHgh+RrTsqyYdzHRfuuq/qatgA2rjdkN0Wt7MbeCArelCGlK/AWOEnv6M4Xby6jt29env4emw0Xe3c7LkqMZk2Q=@vger.kernel.org
X-Gm-Message-State: AOJu0Ywn3YOooSFpvH6fuASxNjLUIVFnB/J2Pj8XNKSx9Cws51Cj2kWn
	WTSW7Lomir2khm3Jx/FzluxzmUwuZtUEXrbRQQ35QdavhBKViAikFJVVERo8i/aIZasDhbMdSeg
	0KXPa7K3qRoffq1wXufoWBJzRMbdyR4e5WC7YiN7k
X-Gm-Gg: AfdE7ckG6b904m1Wfu0IDbeU610zOQwZU+dxf1pZf1R3CjxpaHAJLszGKf5NsnRIc5R
	qRterAN0sjUwefDtFslgqUiVH4yTRsdYaWqtZWsdzai8Cbkw+q8jpV9teHm3LhSf85QbPRT770g
	40HnyDKraKxiJVwnIr8UEFPprG9sqNfhxGg2Mywvvqn239Bin03PTKGZ09XlRR9wA1wOVXAIWzl
	RJ3WBbFfCzNL0kS9qbJS6bQjcNIMgtrBQuaIuerZOaJ11BoDIQLhcMSrj5hK73UHKUw1nr4
X-Received: by 2002:a05:6a21:4d8d:b0:3bf:6c08:fb88 with SMTP id
 adf61e73a8af0-3c0bd313075mr9686335637.56.1783630327482; Thu, 09 Jul 2026
 13:52:07 -0700 (PDT)
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
References: <20260528174140.1921129-1-dmatlack@google.com>
In-Reply-To: <20260528174140.1921129-1-dmatlack@google.com>
From: David Matlack <dmatlack@google.com>
Date: Thu, 9 Jul 2026 13:51:40 -0700
X-Gm-Features: AVVi8CdhJLwo6sRrGOXr_e_pr3F9cmxcWsxeSsKwSQ6kjaqHTtDzZY559HPvSCw
Message-ID: <CALzav=diio783dFmPGYp9Uvov2HBWv_EQLoNjnM=qBWzwU5tCA@mail.gmail.com>
Subject: Re: [PATCH 0/2] liveupdate: Small FLB fixes
To: kexec@lists.infradead.org, linux-kernel@vger.kernel.org
Cc: Andrew Morton <akpm@linux-foundation.org>, Mike Rapoport <rppt@kernel.org>, 
	Pasha Tatashin <pasha.tatashin@soleen.com>, Pratyush Yadav <pratyush@kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, May 28, 2026 at 10:41=E2=80=AFAM David Matlack <dmatlack@google.com=
> wrote:
>
> This series has 2 small fixes to how FLBs are managed. First is to
> increase the outgoing FLB refcount during liveupdate_flb_get_outgoing()
> so it cannot be freed while the caller is using it, and to align with
> the semantics of liveupdate_flb_get_incoming(). The second is to prevent
> FLB retrieve() from being called multiple times if the first attempt
> fails.
>
> Both of these changes are needed for the correctness of the PCI core
> support for Live Update:
>
>   https://lore.kernel.org/linux-pci/20260522202410.3104264-1-dmatlack@goo=
gle.com/

I'm wondering if we still want this series. After discussions with
Pratyush and Sami (some on-list, some off-list) the v7 of the PCI
series (which I haven't sent yet) does not depend on these changes for
correctness.

Patch 1: PCI core no longer calls get_outgoing() outside the scope of
file handler callbacks. So there is no need to increment the reference
count. We could still keep this to make get_outgoing behave the same
way as get_incoming for consisteny at the cost of some extra
complexity to manage outgoing FLB refcoutn.

Patch 2: PCI core panics if retrieve fails (proceeding without the PCI
FLB can lead to memory corruption due to ongoing DMA). So the behavior
of LUO on retrieve() errors does not matter.

Should we drop this series?

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 E5AB0407CDB
	for <linux-kernel@vger.kernel.org>; Fri, 10 Jul 2026 09:57:57 +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=1783677480; cv=none; b=WhlnwKiCKVKMLtKMYbUwYTLd94Rw6rZh8JdYEe9nogRY7p4n66pa3DHO+9Mr/cw353APnyPCygnBxuaTgwQZtVLjtUCx98bDGWyvbVjM1O5UkSys9tIUZKTZtVAVT9S5yYMK0RRXO2ljBend6EGlhl7nICgE1VsBuA5Bfmnb3hs=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1783677480; c=relaxed/simple;
	bh=UDQ5iSt0yl+hIS2B9AYpnE8mlz1A06U4Mo8n6zMKKs0=;
	h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID:
	 MIME-Version:Content-Type; b=hGyvqpz71tLqvvMjaTHVZdOQjEj8JILpzINFAubxfPH2lNv2rGErtqB5DGIXXF0rhMFF83pq3ptjSv6HX5PJvEUrZvzjUGa6+C4f1/suQOlOCOI5ty3pOHMVvmnHL8hbYmjU0Sbqxu3Ho+geUjuJzk8MptF0Zyt8WOOEf26kfLE=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=TGdSxBmC; 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="TGdSxBmC"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 243BB1F00AC4;
	Fri, 10 Jul 2026 09:57:54 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org;
	s=k20260515; t=1783677476;
	bh=ghnk+dbD6A1tyBxAoJ0s58GH07hqyxQ8En0ljy8NSzs=;
	h=From:To:Cc:Subject:In-Reply-To:References:Date;
	b=TGdSxBmCa3CX6xvbAEFyBmy54ptb092aSrGXAj0uHBoTNg0nhY6ta2T08zktnYTjy
	 RmwCy/53WzEom34Uzl6wWZnDMaiRiTOQrpzZamOPTxzbcut6EYwnzYUJRpo49K97yz
	 MvbMiEbs4MlqFZhrVE3VCZ9EsTKOC1FxkQ/EHiQGYUsw74pOoP/nQiqau3WK8TbG6O
	 a8YbSJuX4NwbYzQrMOKIj/rvDWY6d07c2ZSaGStju0F9xL+fbGqhhaUFyDcmmv57li
	 3bGqH1AAM4ddrbgCEcxvv+cRipBFYfEMlBOO2pl87lXttd3O7KEQSefABHBWi0FrVt
	 G2gDSfddFwVRw==
From: Pratyush Yadav <pratyush@kernel.org>
To: David Matlack <dmatlack@google.com>
Cc: kexec@lists.infradead.org,  linux-kernel@vger.kernel.org,  Andrew Morton
 <akpm@linux-foundation.org>,  Mike Rapoport <rppt@kernel.org>,  Pasha
 Tatashin <pasha.tatashin@soleen.com>,  Pratyush Yadav
 <pratyush@kernel.org>
Subject: Re: [PATCH 0/2] liveupdate: Small FLB fixes
In-Reply-To: <CALzav=diio783dFmPGYp9Uvov2HBWv_EQLoNjnM=qBWzwU5tCA@mail.gmail.com>
	(David Matlack's message of "Thu, 9 Jul 2026 13:51:40 -0700")
References: <20260528174140.1921129-1-dmatlack@google.com>
	<CALzav=diio783dFmPGYp9Uvov2HBWv_EQLoNjnM=qBWzwU5tCA@mail.gmail.com>
Date: Fri, 10 Jul 2026 11:57:53 +0200
Message-ID: <2vxzcxwvkvz2.fsf@kernel.org>
User-Agent: Gnus/5.13 (Gnus v5.13)
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Thu, Jul 09 2026, David Matlack wrote:

> On Thu, May 28, 2026 at 10:41=E2=80=AFAM David Matlack <dmatlack@google.c=
om> wrote:
>>
>> This series has 2 small fixes to how FLBs are managed. First is to
>> increase the outgoing FLB refcount during liveupdate_flb_get_outgoing()
>> so it cannot be freed while the caller is using it, and to align with
>> the semantics of liveupdate_flb_get_incoming(). The second is to prevent
>> FLB retrieve() from being called multiple times if the first attempt
>> fails.
>>
>> Both of these changes are needed for the correctness of the PCI core
>> support for Live Update:
>>
>>   https://lore.kernel.org/linux-pci/20260522202410.3104264-1-dmatlack@go=
ogle.com/
>
> I'm wondering if we still want this series. After discussions with
> Pratyush and Sami (some on-list, some off-list) the v7 of the PCI
> series (which I haven't sent yet) does not depend on these changes for
> correctness.
>
> Patch 1: PCI core no longer calls get_outgoing() outside the scope of
> file handler callbacks. So there is no need to increment the reference
> count. We could still keep this to make get_outgoing behave the same
> way as get_incoming for consisteny at the cost of some extra
> complexity to manage outgoing FLB refcoutn.

I'm neutral on this one. I'll leave it up to Pasha's preference.

>
> Patch 2: PCI core panics if retrieve fails (proceeding without the PCI
> FLB can lead to memory corruption due to ongoing DMA). So the behavior
> of LUO on retrieve() errors does not matter.

This patch is useful for sure. Sure, PCI might panic, but other FLB
users like HugeTLB won't. And this patch fixes a real problem for those
cases.

The patch applies cleanly on liveupdate/next. So Mike, would you mind
applying patch 2/2 now? We can wait for Pasha to chime in for 1/2.

>
> Should we drop this series?

--=20
Regards,
Pratyush Yadav

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail-qk1-f179.google.com (mail-qk1-f179.google.com [209.85.222.179])
	(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 D554131195C
	for <linux-kernel@vger.kernel.org>; Sun, 19 Jul 2026 17:09:27 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.179
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1784480969; cv=none; b=phmjbshRhPf4QxQzN0ODyfy6WDOCbfwH3aAUF3CdyWQRv4rY8aIFLme1q3/TjtOxwk3Yh5r32aO3IVczWicJeg9Y3fB1Evu2jhiiVu0lAfmEiQ/svWilGhIicFOSiyi2iDOWiU1v4kjEaNmZbmmRbirGsxl/RJ+UlJibfMQLSm8=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1784480969; c=relaxed/simple;
	bh=490B63b7GfzdXl51Zrnb1jR64vigMAP5fV4sVKDKHWw=;
	h=From:To:Cc:In-Reply-To:References:Subject:Message-Id:Date:
	 MIME-Version:Content-Type; b=CBOCsbwUPcWjIrsqXqSynyBNOaeMrV+DDKtPi3m82Ch+n9syWsgCdOWOBu7g2F/B1mxIGH4K20TFLc/c4wjMOCgt3GMbsh1EamXTtIQG2EMX+aC2ESVSGraeiH4RIPGbhZkqidLcvfgy8bVmRhzq8VyivHa7aiZkF2ahIeEVoOY=
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=ffOTiS4A; arc=none smtp.client-ip=209.85.222.179
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="ffOTiS4A"
Received: by mail-qk1-f179.google.com with SMTP id af79cd13be357-92e50979c71so1024769585a.3
        for <linux-kernel@vger.kernel.org>; Sun, 19 Jul 2026 10:09:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=soleen.com; s=google; t=1784480966; x=1785085766; darn=vger.kernel.org;
        h=content-transfer-encoding:content-type:mime-version:date:message-id
         :subject:references:in-reply-to:cc:to:from:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=Hi0SGV5F/5QPo8XX0tA2GM/CvWtlCpdy3l4mMqNXe0k=;
        b=ffOTiS4A8vfdE59ekylmRPr+xuOaeQsgdO9L2Fklkhh1j4EQ2QYjFHNI8pgUItO66n
         yJtcWGYP74tg5g0BqL4KzLslSn91Ektrueqir0XKqulxW7MtzlM1L3uZFCPwC4fX7cbp
         KUy3qKCQ2y++GqaQDAJOMHr0xFKBGPs3Yqc9KekAxQXch/N7esSRb10zrHdfPBTUJI4W
         XEmCGahaAQ88kdrwg7FmP/QV/pzdk+E1Q9FrIy3Hyd+ntd4B9keZFrq2bVzRF49GOc8L
         f/hoJeuaRRpr4R49f+P+QUG+TDo6EmJ+Pcv7K49Kxy3nDO/TzPzYE4SCz8nePNvhpZml
         5icg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1784480966; x=1785085766;
        h=content-transfer-encoding:content-type:mime-version:date:message-id
         :subject:references:in-reply-to:cc:to:from:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=Hi0SGV5F/5QPo8XX0tA2GM/CvWtlCpdy3l4mMqNXe0k=;
        b=mvz21vcSWQtNP/ZASu/acDek2yK95EckL7duA9Aj4n9QWx+IFSqF4KKOZHgAs56ISy
         Dczn+DfWH/MU24/UPGBZcuDb4/DAMTQ612KU3SCMdCD2WQ2/KQIesEFL4U5zHPAcK8iK
         dKxt7uzr0QWTIfXeWszx7iUkiLOpjFmRNXGdrpmDRzh1WuXO4RR/yNjBelC/plRRzDvy
         9FoQrtykYq7gXoIm2Uuu6eFjL651QMy+1wUbnfwcpuC39rnKWY/mPZjHW+j+KYKPNqHN
         4T3V2HHwqRbVAZs+8jU4Xa7MOE79mjoiSvLef0zXul7ApfrWhhlTbL+Ycpz8RfXHCXQ0
         gPuQ==
X-Forwarded-Encrypted: i=1; AHgh+RrURnAHDGIVA64vIwnlNCa2eTUCNHo4VSfD/EMJDYu76cC1ED8gEOvAJtsIPwUDCjhkpmcKJ2vUeYkhaPM=@vger.kernel.org
X-Gm-Message-State: AOJu0YwmCeNOxQd9JvZ3wn5cA/g2P0j70QrTX5o4XjdrsY+CejnrM0Iu
	bT+ZL4d05ZngmGRm16UUU0TvbAYQ5gR9aLR8Oq/4C4Ol8PnLCDVxSME3SeDhwd7LkGWzgkmeNRc
	5rhxH
X-Gm-Gg: AfdE7cnoXkh+t1oG+zRzhjjSN/AUerJ16iwUO9s6m1gltqP1Xk9pkLZy2aNM7Vl2/pg
	sHyG13K90jwSa5f3lqArWl9qAQEoeNzHlx+nkk+W5IXMkUnFl1m0VtqXWJ56mW85hnLuYmDnUfB
	p/OCHi8yu1Dwa2NoBgtSKVx+FRp/8gnYYFd2QdrjJ7gKtup/lVHL4fevPJkWSw9k+tz1wR9kRco
	T9vLkwk8bTpHGIboLRiutOGsiMIIJG8lEAq486MhrtVA1PFZIglhsJnA2N3VxRTDHZ7N3rth5Wr
	q+EEK+E+zMhffrr6C5JGWqgy2iXsWYOgIR/aT5aN4qbOiUGlJgqrYW6eK6iBbGRHtfHRcj3e+1G
	KbfAkNk3IT+wfQsWrS1rZNvb4X9iiLHNRG3x/IWmUoMUxybmEUuOp+ER9CNAJ5Qp4esUhrkG1jN
	KLrzBRESQSaLhtLIl2bpYkNa7/jGKXKcvoVU9hWbc=
X-Received: by 2002:a05:620a:468e:b0:92e:9d63:a6f6 with SMTP id af79cd13be357-930b3eaa9fbmr1122131885a.17.1784480966677;
        Sun, 19 Jul 2026 10:09:26 -0700 (PDT)
Received: from [127.0.1.1] ([71.181.43.54])
        by smtp.gmail.com with ESMTPSA id af79cd13be357-930b5494153sm686226385a.43.2026.07.19.10.09.25
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Sun, 19 Jul 2026 10:09:26 -0700 (PDT)
From: Pasha Tatashin <pasha.tatashin@soleen.com>
To: kexec@lists.infradead.org, linux-kernel@vger.kernel.org, 
 David Matlack <dmatlack@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>, 
 Mike Rapoport <rppt@kernel.org>, Pratyush Yadav <pratyush@kernel.org>
In-Reply-To: <20260528174140.1921129-1-dmatlack@google.com>
References: <20260528174140.1921129-1-dmatlack@google.com>
Subject: Re: [PATCH 0/2] liveupdate: Small FLB fixes
Message-Id: <178448096578.306041.16503153363800577876.b4-ty@b4>
Date: Sun, 19 Jul 2026 17:09:25 +0000
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Mailer: b4 0.15.2


On Thu, 28 May 2026 17:41:38 +0000, David Matlack wrote:
> This series has 2 small fixes to how FLBs are managed. First is to
> increase the outgoing FLB refcount during liveupdate_flb_get_outgoing()
> so it cannot be freed while the caller is using it, and to align with
> the semantics of liveupdate_flb_get_incoming(). The second is to prevent
> FLB retrieve() from being called multiple times if the first attempt
> fails.
> 
> [...]

Applied, thanks!

[1/2] liveupdate: Reference count outgoing FLB data
      commit: 820d139e43c045c3df7d03d35c78ef766a64f1ee
[2/2] liveupdate: Remember FLB retrieve() status
      commit: f03f4d61010786cf38fa8cdae640e8f965002d45

Best regards,
-- 
Pasha Tatashin <pasha.tatashin@soleen.com>


