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 ; 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 To: David Matlack Cc: kexec@lists.infradead.org, linux-kernel@vger.kernel.org, Andrew Morton , Mike Rapoport , Pasha Tatashin , Pratyush Yadav 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: List-Subscribe: List-Unsubscribe: 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 [...] -- Regards, Pratyush Yadav