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 ; 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 ; 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 To: Pratyush Yadav Cc: kexec@lists.infradead.org, linux-kernel@vger.kernel.org, Andrew Morton , Mike Rapoport , Pasha Tatashin Subject: Re: [PATCH 1/2] liveupdate: Reference count outgoing FLB data Message-ID: 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: List-Subscribe: List-Unsubscribe: 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 > [...] > > -- > Regards, > Pratyush Yadav