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 93E842F12C6 for ; Wed, 6 May 2026 08:47:49 +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=1778057269; cv=none; b=WZL3NtahuIgxoyHBDpPTITAZR7a5D9GPPMn/+HDUIckTiPxN1wxMWTKVjvTYnFs70TUqHC+hO9LeXC9f1Hkg4RK8WhxPkUgQD7Ur0wtCT7hrvAnm5oSHeVVEoAUolLX48YgOMJuQG+Qx/VDdVuoRhGnbdx00j5KF/Os2JlwLekQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778057269; c=relaxed/simple; bh=7IY2kmj0Uq/Ygn9gMXVOL2Kvoevz8GXb2KpMAGJV8SQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=Wd7D96HCl8DE3Bpce13ocQ8Ipssa554v4T+aRBXX0EduuaQIDxDVkEXBEXdE8lynsQUAiz+SToHxXLZskpwZsBSZmJ7xniL+USNzaOR4MCprzLYVJ7Wl07DFfuLYL0yzJr4ZO7G5LotZEeeIDwR5tsLqIwR72wrc8dhDsFmhZY0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=LzLZEk0J; 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="LzLZEk0J" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D025CC2BCB8; Wed, 6 May 2026 08:47:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1778057269; bh=7IY2kmj0Uq/Ygn9gMXVOL2Kvoevz8GXb2KpMAGJV8SQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=LzLZEk0JJGjgAgySvJuH0Yri/edZBEZvNCyBm7MuZEA3krQ0l8r09mVWTy41OoxT6 DOvbOYJQYKOLXszAcAyT1WRtBTzEIYN+spqpyGvl0QduCL1Iw4L/S76YG729tevuGB F50mCGX0pFYkkOnA2FQbwTrXwQNog1uKUxTUBfmYZuNeYBnFbdoVrqWMVLGdmO9Zsx K6VdwglVNXF6xnXGKlDRWZPrnTPsQvUtn6nLvfe1wRcirflapOqMfGaBpkZP9F9lz2 wTJaOWQc8/hoy6yIOZzCom/bJGL9TquxIivme4Ze6nkxWJiCNWi3QK7YBEIqnxII2d O9zI9G74dG38Q== From: Pratyush Yadav To: Pasha Tatashin Cc: rppt@kernel.org, sourabhjain@linux.ibm.com, jbouron@amazon.com, akpm@linux-foundation.org, bhe@redhat.com, linux-kernel@vger.kernel.org, dan.carpenter@linaro.org, liaoyuanhong@vivo.com, rafael.j.wysocki@intel.com, piliu@redhat.com, kexec@lists.infradead.org, pratyush@kernel.org, graf@amazon.com, mario.limonciello@amd.com Subject: Re: [PATCH v1 2/3] liveupdate: block outgoing session mutations during serialization In-Reply-To: <20260506043200.2025677-7-pasha.tatashin@soleen.com> (Pasha Tatashin's message of "Wed, 6 May 2026 00:32:03 -0400") References: <20260506043200.2025677-5-pasha.tatashin@soleen.com> <20260506043200.2025677-7-pasha.tatashin@soleen.com> Date: Wed, 06 May 2026 10:47:45 +0200 Message-ID: <2vxzy0hwzzym.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 Wed, May 06 2026, Pasha Tatashin wrote: > Introduce a 'rebooting' flag in the session header to ensure that once > serialization has started, no new outgoing session mutations (creations > or file preservations) can occur. Would it be a better idea to hold the session header lock and locks of each session? This would prevent anyone else from getting access to any of the sessions, and we don't have to worry about all the weird cases when one might add a file to a serialized session or something similar. Once liveupdate_reboot() returns success, there is no going back anyway so I don't think it matters much that some tasks will be left waiting. > > Fixes: 0153094d03df ("liveupdate: luo_session: add sessions support") > Reported-by: Oskar Gerlicz Kowalczuk > Signed-off-by: Pasha Tatashin [...] -- Regards, Pratyush Yadav