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 3B9FB2765D7 for ; Thu, 28 May 2026 14:51:56 +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=1779979917; cv=none; b=ugDed/ojatUV5TX/YfvH3zGEqkDV0ou32Uope7IzaOssVhf1w/ICjYa3N/VyWth6yYHLEqyQtlKuUIKZeLQNiDf4iu0HRo0aCK40k8m02pywWKSkZQkLIt9InTZ1wZNqKEXIMIJcPXGDghdh4HLENfK5Mghakv5wrmBMpTyzyI8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779979917; c=relaxed/simple; bh=+O9swPdRYodmms06X7dTJokpEDcjfO6f9lKlfk+N5Ps=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=jUmNmTTyT0/7NZRy+JlEgoitb0nwwBzksQLCMbdJMDlfKpm1cyLfKsu7K9BryzRDKlIr9nGZqLRIBkoJSxFnRURvF2DPfVUMCr4tWpNpCQ3MHYNlbQjH9RmlY/ZouPTfcvMBWhxRCHaUSKtIikNXGwmmxfQsTpNi3CbLZ7b2nBo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Uwp9VVVl; 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="Uwp9VVVl" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 82AC81F000E9; Thu, 28 May 2026 14:51:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1779979915; bh=mak8BcDRmJI9QTAk7PBzShu7AY5kBLAAqcpwHsNXbNo=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=Uwp9VVVlovjSGtHdqmf9FDdQqQcGbFNt+BgKqZ+lBhGJS8evJUIMk6guf3KfKHcg3 UfiNS+sgaTVfYr9eIcBK3aDZy1MFXYN/Bi/+vaeF8GYN94P7oafAntf0JS3KUf+JER tI0H2Ida5sJmysfH1nljjpNMpOxFH1/LXYiS9K0Axpmhqob5+vwIwjK7NuGkIGDQsM 7jsVEp+iFtvZACdjK0tjg0ECdgYGaA9isRlBhzIHbrA/R1XUpiLW+e0P0TV0kk7row jP1MbP+/8xMwhNyuqvGJcCtFjWJEUWtBgd42uoWcjc9LSDKT7GwPlKwSLbWfNqHAUl GxAMXX2OD/jiA== Date: Thu, 28 May 2026 17:51:47 +0300 From: Mike Rapoport To: Pratyush Yadav Cc: Pasha Tatashin , sourabhjain@linux.ibm.com, jbouron@amazon.com, akpm@linux-foundation.org, error27@gmail.com, bhe@redhat.com, linux-kernel@vger.kernel.org, rafael.j.wysocki@intel.com, piliu@redhat.com, kexec@lists.infradead.org, skhawaja@google.com, graf@amazon.com, mario.limonciello@amd.com Subject: Re: [PATCH v6 3/5] liveupdate: block session mutations during reboot Message-ID: References: <20260527202737.1345192-1-pasha.tatashin@soleen.com> <20260527202737.1345192-4-pasha.tatashin@soleen.com> <2vxzv7c739a2.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: <2vxzv7c739a2.fsf@kernel.org> On Thu, May 28, 2026 at 04:20:53PM +0200, Pratyush Yadav wrote: > On Wed, May 27 2026, Pasha Tatashin wrote: > > > During the reboot() syscall, user processes may still be running > > concurrently and attempting to mutate sessions (e.g., creating, > > retrieving, or releasing sessions). To prevent this, introduce > > luo_session_serialize_rwsem to synchronize mutations with the > > serialization process. > > > > All session mutation operations (create, retrieve, release, ioctl) take > > the read lock. The serialization process (luo_session_serialize) takes > > the write lock and holds it indefinitely on success. This effectively > > freezes the LUO session subsystem during the transition to the new > > kernel. If serialization fails, the lock is released to allow recovery. > > > > Fixes: 0153094d03df ("liveupdate: luo_session: add sessions support") > > Reported-by: Oskar Gerlicz Kowalczuk > > Acked-by: Mike Rapoport (Microsoft) > > Signed-off-by: Pasha Tatashin > > --- > > kernel/liveupdate/luo_session.c | 56 +++++++++++++++++++++++++++++++-- > > 1 file changed, 53 insertions(+), 3 deletions(-) > > > > +/* > > + * Protects session mutations during serialization. All session mutation > > + * operations must hold the read lock. The serialization process holds the write > > + * lock indefinitely on success to block all concurrent and future mutations. > > + */ > > Nit: this comment is redundant now. I guess you can remove this when > applying. Done :) > Reviewed-by: Pratyush Yadav (Google) > > > +static DECLARE_RWSEM(luo_session_serialize_rwsem); > > + > > /** > > * struct luo_session_header - Header struct for managing LUO sessions. > > * @count: The number of sessions currently tracked in the @list. > [...] > > -- > Regards, > Pratyush Yadav -- Sincerely yours, Mike.