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 A42703E95B3 for ; Wed, 6 May 2026 08:53:39 +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=1778057619; cv=none; b=RPb9rPHLyZBGWs5bJBziwTYBgXI6HvSRYOuQKcI6Lnf8kX7bS/Ppg/BiOg08dfzR7SqLzs5LXQn7rB2iCHx8q11PaR01lhn7anLh9wUIEjJFZ/+1aYk8bMc1m35qSJb8PhHfB3y1zufQOS1VkEI+LYUAZfK4QSBzsZF7xJi32qI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778057619; c=relaxed/simple; bh=7nPqnjcbCwL0xt6SvXlllnq2oT21ELzYOApfrUFK6HY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=RWreJV4eZ1zQYjCJEs31O1s2Dq9AxrgC+iX27+KPV/iNTFN/6QE604TwBKEGBUFIZJzZSdsOcHeRTh6S/qOtOXQcbynLX0FCmqueIQ8PxgYNVuViJg3kYjewBCVHSTjBhWmM/Uq+IMtYwbX7jPgmqun8JDEcLcCoxXf984X7bxg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Cvt1x3sL; 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="Cvt1x3sL" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6E0C2C2BCB8; Wed, 6 May 2026 08:53:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1778057618; bh=7nPqnjcbCwL0xt6SvXlllnq2oT21ELzYOApfrUFK6HY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Cvt1x3sLIqFHyinhL5mHeD5/hAflSnAzfTmfzstfDkR6/cUsiZcVCxgbubNL3slcw ZpjhgFwfJj4ekADWRN7VPECArnPUN6EjoD8bw+lUe/ilMXgHB05Dpt1eXIYjFL95/Q 5mdsLprp5YYdtjA4IFAip7brC8eAw8Xh9BabObRhLzvy1f0t8tYufgoU0eA1Lyi/+0 Wj/+r9nURDqRbQ0951ql2YECT8JVXfIXnPvaCMS27YFVSKZTnBqNxh10ZIs4D5zkTD w1wQsGXHOaTCGQe9VsqJaxziucvka+4gTd3VK8nJ657C6Gly2K2H3LSKm+UjB4msvm Q1CnD1lEBYLxg== 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 3/3] liveupdate: pin sessions and handle inactive ones during serialization In-Reply-To: <20260506043200.2025677-8-pasha.tatashin@soleen.com> (Pasha Tatashin's message of "Wed, 6 May 2026 00:32:04 -0400") References: <20260506043200.2025677-5-pasha.tatashin@soleen.com> <20260506043200.2025677-8-pasha.tatashin@soleen.com> Date: Wed, 06 May 2026 10:53:34 +0200 Message-ID: <2vxztsskzzox.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: > During the reboot() syscall, user processes are still running > concurrently. Even though the system is actively serializing LUO > sessions and will not return to userspace unless liveupdate_reboot() > fails, it is still possible for a user process to close a preserved LUO > session. This creates a race condition where a session could be > destroyed while it is being serialized. > > To fix this, we must ensure that we only preserve sessions that are not > closed at the time of serialization. Take a reference to the session's > struct file for all outgoing sessions to pin them during this process. > > Handle inactive sessions (where get_file_active() fails) by cleaning > them up and removing them from the outgoing list during the pinning > phase. This ensures serialization can safely proceed with the remaining > active sessions. > > Fixes: 0153094d03df ("liveupdate: luo_session: add sessions support") > Reported-by: Oskar Gerlicz Kowalczuk > Signed-off-by: Pasha Tatashin Same here. If we hold the session header and session locks, we don't have to worry about all these corner cases. It is too late to touch the session once liveupdate_reboot() starts, and if you try you just get put to sleep. [...] -- Regards, Pratyush Yadav