From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 9215D2D3ED1 for ; Thu, 2 Apr 2026 16:21:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775146880; cv=none; b=P31EbbKd5L3C1cXx6WicapECezmTZD7jPak4VAsDgmeoJgdHD0owb0RVFLsOryY8N0cJ7ez1FDD/prtNvUT0Ylo7UfgnjSipoDJodiwEyiYTEUQQcAqSH0HBX3i4EebF/C3/s5nsrrvofgVAwA8l0J/YRAYKdFE3UB3jx1STmv0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775146880; c=relaxed/simple; bh=VPxvQSupAhaLkBsECVCyj57o8OKTQESUiFeywVyxy70=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=Fdm9eho3tfGeZIXdYvf9PPESQIPq8eEtuA44Emg9FkLOL+hItBAiqAGDkbmIYwTNRYHlGEBE9txM8NaviL1zNxaggaYzWvvSQ6edmLeJK51jpoXgTm5GnjlkNwpDMLsNmrUFtCBYz4XtzKH4G8qaUg7+E2ukqmILh19qEg20FKo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Il8ShCZX; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Il8ShCZX" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6F5FCC116C6; Thu, 2 Apr 2026 16:21:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1775146880; bh=VPxvQSupAhaLkBsECVCyj57o8OKTQESUiFeywVyxy70=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Il8ShCZX8EniFze/XLUq0ESVGJkvF9U52IZtwOd63sP95QkCFdfBCmd6214CoRXqh 9FOUAYd+kcRuhIVok+E2KqtOjkpyTQNpZ4OrOuBUrBsZvuNd73ERy/eSMnYIJySJx9 MIfPupm6DEiHYhXc8qwuFkI7jwY5lL+WS11U7N+/jWopkWqmkm9HjGcmWOPhU9nZtH 8AuVObOcb2JUeSkVjYaE2uXUu61LCBMCwb3fI2ddw+c/Lmpz1kwXQDKmrF4w1CRXLH 0kwy7iFfF8TQWrT53qfNwHKLIYqqk7AF2SjzR8GnAzRVg3PThe+AMI1jkXMn5w10Q6 3/QWVMp7YODeA== From: Pratyush Yadav To: Pasha Tatashin Cc: rppt@kernel.org, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, dmatlack@google.com, pratyush@kernel.org, skhawaja@google.com Subject: Re: [PATCH v3 05/10] liveupdate: Defer FLB module refcounting to active sessions In-Reply-To: <20260327033335.696621-6-pasha.tatashin@soleen.com> (Pasha Tatashin's message of "Fri, 27 Mar 2026 03:33:29 +0000") References: <20260327033335.696621-1-pasha.tatashin@soleen.com> <20260327033335.696621-6-pasha.tatashin@soleen.com> Date: Thu, 02 Apr 2026 16:21:16 +0000 Message-ID: <2vxza4vlfi4j.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 On Fri, Mar 27 2026, Pasha Tatashin wrote: > Stop pinning modules indefinitely upon FLB registration. > Instead, dynamically take a module reference when the FLB is actively > used in a session (e.g., during preserve and retrieve) and release it > when the session concludes. > > This allows modules providing FLB operations to be cleanly unloaded > when not in active use by the live update orchestrator. > > Signed-off-by: Pasha Tatashin This is good for now but I think we should rework the FLB registration down the line. File handlers should not use the FLB before registering first, and we should initialize the FLB on registration. At this point, if there is incoming data for the FLB the module reference should be taken since now there are files depending on that module. Reviewed-by: Pratyush Yadav (Google) [...] -- Regards, Pratyush Yadav