From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f171.google.com (mail-pg1-f171.google.com [209.85.215.171]) (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 2F2E6420484 for ; Wed, 15 Jul 2026 16:07:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=209.85.215.171 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784131653; cv=pass; b=N7iaPQ8bHBZ+pH4q/yxkUAhomYb+XoO2gRwM7UjxvKFZEZFgHwKDWKY8Apy8kPkLExnrra01veDqjiFJDDmlRtZo9dqBA2nnZVXjR0b2tiFDjuokYnN0TTRe+cUUqXWMvOFpQ9AfnurFK6QiEg3ZqdTqWmt9L6OyTwUUw3/0ANQ= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784131653; c=relaxed/simple; bh=HJQEKCViAQqXKFGqMHAnjJNWD8wzpW5b0Px0rcjj5wM=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=k7zHMtuH+E8y8OStZDlvNpP6flrZMCnp6yAJbggqpJJ0AkSVx8GHbV2YiPSXiwIrwymwqDWY5y3kJwcSsFbrdGPQ3mqJIiOroilbYJbqnyMRy+hZ74gYmkVc0mQbT7hGaBaYak94QVeN6tjyizOB0NJwQ+Rxl9Q+lh+9dHCtNQc= ARC-Authentication-Results:i=2; 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=mwDqzXlf; arc=pass smtp.client-ip=209.85.215.171 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="mwDqzXlf" Received: by mail-pg1-f171.google.com with SMTP id 41be03b00d2f7-c9d1fc053e0so2031554a12.1 for ; Wed, 15 Jul 2026 09:07:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1784131651; cv=none; d=google.com; s=arc-20260327; b=VsQ6SpB0cDvgb7gaJCLjQ6JxnE9lHs7hG4jMIqgsdZqki3ngkdpu3rrvaFXNVX+489 p+g5ZUOA6xLc2ZMZJI0ZAgAdR+EvZxo3eabl23H8r5DjpcSTXYy800ow5SD+R4KFVIoR iPqO53Lgj34VTqAdZ8cA6QeP+lifEJXhIPnLkIyJeQ9j1mNrTlufg5ZrIIIBP+GEgcu3 TqxRv0A/8TTIfdC+1WedygQXjZIdaIHQCXjAm+rOeQoPI/cECR86nCrmJlozn9lIlJ3h n3R54OJFGP1jHr8AdrPOASn15pP/wycX7VjPNpoDdzyKVdVQRwBCIdZF+qhZBVQ8CUsi UXqQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=H12olXVq3F1RAP6MWw5onyOkfq0/I6cz4mvSnYOiLBA=; fh=I5QK7Ys/7avoxvAWUOMoPL/qktzUtFavL17mW4YwzNc=; b=sos1Dp7H10M/0zpU4abEMcHw89mHqDAS3jET7uITb+lVOjBSE6QI1pPDiubeACJqte 7aGT5XWSEDEuvaSNbdYgo+hrkimV324KpWFrvBr/fe2Cs0vOdNuOKC5jSgt+2R7FdWsa UPxsKik66meZYuLNX6a2vpNjg/luAqIn9bULyVbD6+iftMIr3ZUKDCjxn20SgowBs9bS PCe5zhIyCxMTe+c87FMinWgxiaGWT1eJcwGD4cdv+C9r9ekC/FvsJaaHtCtarHy7vZAf JV0HTWz79bcP3FjPQTdk/MebNFOitl1tjQTkBxohiCr6KcTldw/vy62afLuwAHPm0miV NP8g==; darn=vger.kernel.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1784131651; x=1784736451; darn=vger.kernel.org; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:from:to:cc:subject :date:message-id:reply-to:content-type; bh=H12olXVq3F1RAP6MWw5onyOkfq0/I6cz4mvSnYOiLBA=; b=mwDqzXlfWAf9NfNpDTAJL4dU/1MQ9xvpQNu/BBgP7SMs/yxD3AoApqupbszn9MZlKi gxhcTIXotwPLNX/q3JKTyTb0EwFkOVrBMZsclyWon4jP8/asgErRRhVaQTTXPEateOaP 38op8b0+qO9F6QBfNWMnTdhVxAaE6lQIIBGpd6ULD2YTS0gQCTdo9rdHX52bzErORA9G +s5jepYLNqiJ92xQV4u9b/qX2FvPfFPhgvtPwooOCNsAT9sFkSMwqAPel/Kt9GXucDRB fw+a1TWyKG7xcCnorHvI9ZoF0rciFyO0h/kK3RrmnL6UIUYX6EDcXWE+y0AUx1mJ3/p+ c6ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784131651; x=1784736451; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=H12olXVq3F1RAP6MWw5onyOkfq0/I6cz4mvSnYOiLBA=; b=LW2GfkGbEGVFyrJQgNrkjlWCDrGe8mWvc9wMfEbd7qGi/WBB1yLOM+MmAADE/+iVOq buQgB5c5MAfvk9Jh0wmgQvCHgVYYGjSli31X4DjPvOu6/Bl1qYZqfR8YflJcS+3985im Ulhq/D+cC1tTOiR/Y6OOA5p7MpQZcrFoS22JzXxARvFKdZrkZAGL7d19KC2NDy6BC+Us y48y3Fhw4ev00RHy5qgbbyUyRn6oPATNgUdz+S49bu8o63LUPTOGZiYaQekLBwrEcA57 9w3a1wF2+BB9q0f7ZEHXyaJJwJyCGDEx7Sdn6Y82ha7+aXS/8C/rVcS5fl2SnkgfX+CD SZlw== X-Forwarded-Encrypted: i=1; AHgh+RqD2P2wBu1CXpNGx2IFd8u/fkUnu5OCUTOT6tRzaljV+0NXSKGy5+Pl/npKw+gp9gD5D3zid9v0p8Divhk=@vger.kernel.org X-Gm-Message-State: AOJu0YwbN4E1H09txXmKTzgOQThAudML/6WOW1v2hHzMyNpRVnyUiFgv QjTGtxB0yNz48nTu99fSCt2dAHkOiKyMvvWK+NSis1X/T2RLCE2C3yksvEqogGQdlr9rDhfG2XT Z+vGPOxAg3crIOGi0o4upptstaNE+m7o07ekiI8lm X-Gm-Gg: AfdE7cnsc7I3A9vCUe6xXFiBQW/qdj0KRxmgDNMjfJkJT++7b8RArxKudzXHQg3+HBe ig4jfG6HPjRRu3HOR22TuLWhTeSd7JiOe2epYf0pGGfI71YkW/lvxhY6DsgkFBK8ME6xLG984LE hGRGOa6J2QmGDsnwCS3p2OKE8jvNm1FRUXoSIz8ozuPs/+sGycBT1VDxgUI900rEsP29WY67Jvn A46Tjz1M+uOkqbjsQ1A1dCyaF4gy7mV/GlhBuN2Epzl4QCawgt/9uWMee7r3zeMAneU+qYR X-Received: by 2002:a05:6a21:3988:b0:3c3:821e:1f84 with SMTP id adf61e73a8af0-3c3821e43ecmr718389637.41.1784131651046; Wed, 15 Jul 2026 09:07:31 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20260714190356.190328-1-dmatlack@google.com> <2vxzy0fcicpi.fsf@kernel.org> In-Reply-To: <2vxzy0fcicpi.fsf@kernel.org> From: David Matlack Date: Wed, 15 Jul 2026 09:07:03 -0700 X-Gm-Features: AUfX_mwWLIIwIbCORwPju6JjaZTyqkA_jPyoKhqBFYSqQTZxJQormdY_HQIDbQg Message-ID: Subject: Re: [RFC PATCH] liveupdate: Allow multiple openers for /dev/liveupdate To: Pratyush Yadav Cc: kexec@lists.infradead.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, Jason Gunthorpe , Mike Rapoport , Pasha Tatashin , Samiullah Khawaja , Shuah Khan Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 15, 2026 at 6:50=E2=80=AFAM Pratyush Yadav wrote: > > Hi David, > > On Tue, Jul 14 2026, David Matlack wrote: > > > Remove the single-opener restriction for /dev/liveupdate by removing th= e > > atomic in_use tracking and the exclusive open check in luo_open() that > > returned -EBUSY. Protect luo_session_deserialize() with a mutex guard s= o > > that concurrent open attempts by multiple processes safely executes > > deserialization only once. Update liveupdate selftest to verify that > > multiple concurrent openers succeed. > > > > LUO does not inherently require a single opener. There is some > > documentation about it simplifying state management, but the only thing > > it actually protects is the session deserialization during first open, > > which can be easily handled with a mutex. > > > > Relaxing the single-opener requirement avoids the kernel forcing a > > design pattern on userspace that it itself does not require, e.g. > > allowing multiple userspace processes to create and manage sessions. > > Agreed. When the kernel had a global state machine in the early versions > of LUO, this might have been more relevant. With sessions, even if we > later add a state machine, it likely will be per-session instead of > being global. So I think letting userspace open /dev/liveupdate multiple > times makes a lot of sense. > > Also, today's systemd only supports preserving individual files, and > does not hand out sessions. To get sessions, userspace must open > /dev/liveupdate and create a session. This opens up room for one bad > process to block every other process from creating sessions. It also > imposes a need for userspace to add a polling/retry logic for getting > sessions and serializes their execution around this point. > > I don't see any architectural reasons for doing so from kernel's side. > If userspace wants to only have one owner of /dev/liveupdate, they are > free to do so by unlinking the device from devtmpfs after opening or > restricting its permissions. > > So the idea has my vote :-) > > Acked-by: Pratyush Yadav (Google) > > That said, a comment on the code below. > > > > > Signed-off-by: David Matlack > > --- > [...] > > diff --git a/kernel/liveupdate/luo_session.c b/kernel/liveupdate/luo_se= ssion.c > > index b79b2a488974..ca4d0639d39a 100644 > > --- a/kernel/liveupdate/luo_session.c > > +++ b/kernel/liveupdate/luo_session.c > > @@ -584,13 +584,17 @@ static int luo_session_deserialize_one(struct luo= _session_header *sh, > > > > int luo_session_deserialize(void) > > { > > - struct luo_session_header *sh =3D &luo_session_global.incoming; > > + static DEFINE_MUTEX(luo_session_deserialize_lock); > > static bool is_deserialized; > > + static int saved_err; > > + > > + struct luo_session_header *sh =3D &luo_session_global.incoming; > > struct luo_session_ser *ser; > > struct kho_block_set_it it; > > - static int saved_err; > > int err; > > > > + guard(mutex)(&luo_session_deserialize_lock); > > Do we really need a new lock? Can we re-use sh->rwsem instead? > > It can block session retrieve (but not file retrieve) for a short time > though since luo_session_retrieve() also takes it. But the block will be > short since only the first open of /dev/liveupdate does work. After that > it just checks is_deserialized and returns. And session retrieval should > not be very frequent anyway. > > I don't have very strong opinion on this, but I reckon the less locks to > keep track of the better. The lock here is just to protect the local static variables (is_deserialized and saved_err) so that's why I went with a local static lock. But re-using sh->rwsem should work as well and would not block luo_session_retrieve() any more than the current static lock would (opening /dev/liveupdate must always preceded retrieving a session).