[PATCH v2 0/3] liveupdate: serialization safety and race fixes

[PATCH v2 0/3] liveupdate: serialization safety and race fixes

[Pasha Tatashin]

This series addresses several issues related to the synchronization
between the reboot process and LUO session management.

Changes in v2:
- Added a patch to skip KHO data for context-preserving kexec (suggested
  by Pratyush Yadav).
- Dropped the 'rebooting' flag and manual session pinning patches from
  v1.
- Implemented a locking approach in luo_session_serialize() to prevent
  concurrent session mutations and release (suggested by Pratyush).

1. Skip KHO data for context-preserving kexec: A preserve_context kexec
returns to the current kernel, which means the 2nd kernel does not use
KHO data. Passing KHO data via setup_data or devicetree is unnecessary.

2. Skip LUO serialization for context-preserving kexec: A
preserve_context kexec returns to the current kernel, which is unrelated
to live update where state is passed to the next kernel. Skipping
serialization avoids unnecessary work and prevents sessions from being
left in a frozen state upon return.

3. Block outgoing session mutations using locks: During the reboot()
syscall, user processes may still be running concurrently and attempting
to mutate sessions. To prevent this, we hold the session header's rwsem
and each session's mutex indefinitely on successful serialization. This
effectively pins the sessions and blocks concurrent modifications
without needing custom flags.

Tree: git.kernel.org/pub/scm/linux/kernel/git/tatashin/linux.git Branch:
luo-reboot-sync/v2

Pasha Tatashin (3):
  kho: skip KHO data for context-preserving kexec
  liveupdate: skip serialization for context-preserving kexec
  liveupdate: block outgoing session mutations

 kernel/kexec_core.c                |  8 +++++---
 kernel/liveupdate/kexec_handover.c |  3 ++-
 kernel/liveupdate/luo_session.c    | 12 +++++++++---
 3 files changed, 16 insertions(+), 7 deletions(-)


base-commit: 7b0b68b2b95606e65594958686833e53423f58f2
-- 
2.54.0.545.g6539524ca2-goog

[PATCH v2 1/3] kho: skip KHO data for context-preserving kexec

[Pasha Tatashin]

A preserve_context kexec returns to the current kernel, which means the
2nd kernel does not use KHO data (and their memory spaces don't
overlap). Passing KHO data to the 2nd kernel via setup_data or
devicetree is unnecessary.

Add a check in kho_fill_kimage() and return early if preserve_context is
set, to avoid passing KHO state during context-preserving kexecs.

Fixes: 3bdecc3c93f9 ("kexec: add KHO support to kexec file loads")
Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
---
 kernel/liveupdate/kexec_handover.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c
index 4fde8325c49f..2eec2a169c83 100644
--- a/kernel/liveupdate/kexec_handover.c
+++ b/kernel/liveupdate/kexec_handover.c
@@ -1702,7 +1702,8 @@ int kho_fill_kimage(struct kimage *image)
 	int err = 0;
 	struct kexec_buf scratch;
 
-	if (!kho_enable || image->type == KEXEC_TYPE_CRASH)
+	if (!kho_enable || image->type == KEXEC_TYPE_CRASH ||
+	    image->preserve_context)
 		return 0;
 
 	image->kho.fdt = virt_to_phys(kho_out.fdt);
-- 
2.54.0.545.g6539524ca2-goog

Re: [PATCH v2 1/3] kho: skip KHO data for context-preserving kexec

[Mike Rapoport]

On Wed, May 06, 2026 at 02:20:41PM -0400, Pasha Tatashin wrote:
> A preserve_context kexec returns to the current kernel, which means the
> 2nd kernel does not use KHO data (and their memory spaces don't
> overlap). Passing KHO data to the 2nd kernel via setup_data or
> devicetree is unnecessary.
> 
> Add a check in kho_fill_kimage() and return early if preserve_context is
> set, to avoid passing KHO state during context-preserving kexecs.
> 
> Fixes: 3bdecc3c93f9 ("kexec: add KHO support to kexec file loads")
> Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
> ---
>  kernel/liveupdate/kexec_handover.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c
> index 4fde8325c49f..2eec2a169c83 100644
> --- a/kernel/liveupdate/kexec_handover.c
> +++ b/kernel/liveupdate/kexec_handover.c
> @@ -1702,7 +1702,8 @@ int kho_fill_kimage(struct kimage *image)
>  	int err = 0;
>  	struct kexec_buf scratch;
>  
> -	if (!kho_enable || image->type == KEXEC_TYPE_CRASH)
> +	if (!kho_enable || image->type == KEXEC_TYPE_CRASH ||
> +	    image->preserve_context)
>  		return 0;

Sashiko says it's unnecessary:

https://sashiko.dev/#/patchset/20260506182039.2623553-5-pasha.tatashin@soleen.com

I tend to agree :)
  
>  	image->kho.fdt = virt_to_phys(kho_out.fdt);
> -- 
> 2.54.0.545.g6539524ca2-goog
> 

-- 
Sincerely yours,
Mike.

Re: [PATCH v2 1/3] kho: skip KHO data for context-preserving kexec

[Pratyush Yadav]

On Mon, May 11 2026, Mike Rapoport wrote:

> On Wed, May 06, 2026 at 02:20:41PM -0400, Pasha Tatashin wrote:
>> A preserve_context kexec returns to the current kernel, which means the
>> 2nd kernel does not use KHO data (and their memory spaces don't
>> overlap). Passing KHO data to the 2nd kernel via setup_data or
>> devicetree is unnecessary.
>> 
>> Add a check in kho_fill_kimage() and return early if preserve_context is
>> set, to avoid passing KHO state during context-preserving kexecs.
>> 
>> Fixes: 3bdecc3c93f9 ("kexec: add KHO support to kexec file loads")
>> Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
>> ---
>>  kernel/liveupdate/kexec_handover.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>> 
>> diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c
>> index 4fde8325c49f..2eec2a169c83 100644
>> --- a/kernel/liveupdate/kexec_handover.c
>> +++ b/kernel/liveupdate/kexec_handover.c
>> @@ -1702,7 +1702,8 @@ int kho_fill_kimage(struct kimage *image)
>>  	int err = 0;
>>  	struct kexec_buf scratch;
>>  
>> -	if (!kho_enable || image->type == KEXEC_TYPE_CRASH)
>> +	if (!kho_enable || image->type == KEXEC_TYPE_CRASH ||
>> +	    image->preserve_context)
>>  		return 0;
>
> Sashiko says it's unnecessary:
>
> https://sashiko.dev/#/patchset/20260506182039.2623553-5-pasha.tatashin@soleen.com
>
> I tend to agree :)

Hmm, good point. I take back my suggestion then.

-- 
Regards,
Pratyush Yadav

Re: [PATCH v2 1/3] kho: skip KHO data for context-preserving kexec

[Pasha Tatashin]

On 05-11 13:38, Mike Rapoport wrote:
> On Wed, May 06, 2026 at 02:20:41PM -0400, Pasha Tatashin wrote:
> > A preserve_context kexec returns to the current kernel, which means the
> > 2nd kernel does not use KHO data (and their memory spaces don't
> > overlap). Passing KHO data to the 2nd kernel via setup_data or
> > devicetree is unnecessary.
> > 
> > Add a check in kho_fill_kimage() and return early if preserve_context is
> > set, to avoid passing KHO state during context-preserving kexecs.
> > 
> > Fixes: 3bdecc3c93f9 ("kexec: add KHO support to kexec file loads")
> > Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
> > ---
> >  kernel/liveupdate/kexec_handover.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c
> > index 4fde8325c49f..2eec2a169c83 100644
> > --- a/kernel/liveupdate/kexec_handover.c
> > +++ b/kernel/liveupdate/kexec_handover.c
> > @@ -1702,7 +1702,8 @@ int kho_fill_kimage(struct kimage *image)
> >  	int err = 0;
> >  	struct kexec_buf scratch;
> >  
> > -	if (!kho_enable || image->type == KEXEC_TYPE_CRASH)
> > +	if (!kho_enable || image->type == KEXEC_TYPE_CRASH ||
> > +	    image->preserve_context)
> >  		return 0;
> 
> Sashiko says it's unnecessary:
> 
> https://sashiko.dev/#/patchset/20260506182039.2623553-5-pasha.tatashin@soleen.com
> 
> I tend to agree :)

Awesome catch by Sashiko, I will drop this patch.

Pasha

>   
> >  	image->kho.fdt = virt_to_phys(kho_out.fdt);
> > -- 
> > 2.54.0.545.g6539524ca2-goog
> > 
> 
> -- 
> Sincerely yours,
> Mike.

Re: [PATCH v2 1/3] kho: skip KHO data for context-preserving kexec

[Pratyush Yadav]

On Wed, May 06 2026, Pasha Tatashin wrote:

> A preserve_context kexec returns to the current kernel, which means the
> 2nd kernel does not use KHO data (and their memory spaces don't
> overlap). Passing KHO data to the 2nd kernel via setup_data or
> devicetree is unnecessary.
>
> Add a check in kho_fill_kimage() and return early if preserve_context is
> set, to avoid passing KHO state during context-preserving kexecs.
>
> Fixes: 3bdecc3c93f9 ("kexec: add KHO support to kexec file loads")
> Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>

Reviewed-by: Pratyush Yadav (Google) <pratyush@kernel.org>

[...]

-- 
Regards,
Pratyush Yadav

[PATCH v2 2/3] liveupdate: skip serialization for context-preserving kexec

[Pasha Tatashin]

A preserve_context kexec returns to the current kernel, which is
unrelated to live update where the state is passed to the next kernel.
Skip liveupdate_reboot() in this case to avoid serialization and prevent
sessions from being left in a frozen state upon return.

Fixes: db8bed8082dc ("kexec: call liveupdate_reboot() before kexec")
Reported-by: Oskar Gerlicz Kowalczuk <oskar@gerlicz.space>
Reviewed-by: Pratyush Yadav (Google) <pratyush@kernel.org>
Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
---
 kernel/kexec_core.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index a43d2da0fe3e..dc770b9a6d05 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -1146,9 +1146,11 @@ int kernel_kexec(void)
 		goto Unlock;
 	}
 
-	error = liveupdate_reboot();
-	if (error)
-		goto Unlock;
+	if (!kexec_image->preserve_context) {
+		error = liveupdate_reboot();
+		if (error)
+			goto Unlock;
+	}
 
 #ifdef CONFIG_KEXEC_JUMP
 	if (kexec_image->preserve_context) {
-- 
2.54.0.545.g6539524ca2-goog

[PATCH v2 3/3] liveupdate: block outgoing session mutations

[Pasha Tatashin]

During the reboot() syscall, user processes may still be running
concurrently and attempting to mutate sessions (e.g., adding files or
closing sessions). To prevent this, hold the session header's rwsem and
each session's mutex indefinitely on successful serialization.

If serialization succeeds, these locks will never be released as the
system transitions to the new kernel, effectively blocking any
concurrent task attempting to modify or release a session. If
liveupdate_reboot() fails, the locks are released in the error path,
allowing normal operation to resume.

Fixes: 0153094d03df ("liveupdate: luo_session: add sessions support")
Reported-by: Oskar Gerlicz Kowalczuk <oskar@gerlicz.space>
Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
---
 kernel/liveupdate/luo_session.c | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/kernel/liveupdate/luo_session.c b/kernel/liveupdate/luo_session.c
index a3327a28fc1f..12808c696def 100644
--- a/kernel/liveupdate/luo_session.c
+++ b/kernel/liveupdate/luo_session.c
@@ -189,14 +189,14 @@ static int luo_session_finish_one(struct luo_session *session)
 static void luo_session_unfreeze_one(struct luo_session *session,
 				     struct luo_session_ser *ser)
 {
-	guard(mutex)(&session->mutex);
+	lockdep_assert_held(&session->mutex);
 	luo_file_unfreeze(&session->file_set, &ser->file_set_ser);
 }
 
 static int luo_session_freeze_one(struct luo_session *session,
 				  struct luo_session_ser *ser)
 {
-	guard(mutex)(&session->mutex);
+	lockdep_assert_held(&session->mutex);
 	return luo_file_freeze(&session->file_set, &ser->file_set_ser);
 }
 
@@ -583,7 +583,10 @@ int luo_session_serialize(void)
 	int i = 0;
 	int err;
 
-	guard(rwsem_write)(&sh->rwsem);
+	down_write(&sh->rwsem);
+	list_for_each_entry(session, &sh->list, list)
+		mutex_lock_nest_lock(&session->mutex, &sh->rwsem);
+
 	list_for_each_entry(session, &sh->list, list) {
 		err = luo_session_freeze_one(session, &sh->ser[i]);
 		if (err)
@@ -603,6 +606,9 @@ int luo_session_serialize(void)
 		luo_session_unfreeze_one(session, &sh->ser[i]);
 		memset(sh->ser[i].name, 0, sizeof(sh->ser[i].name));
 	}
+	list_for_each_entry(session, &sh->list, list)
+		mutex_unlock(&session->mutex);
+	up_write(&sh->rwsem);
 
 	return err;
 }
-- 
2.54.0.545.g6539524ca2-goog

Re: [PATCH v2 3/3] liveupdate: block outgoing session mutations

[Pratyush Yadav]

On Wed, May 06 2026, Pasha Tatashin wrote:

> During the reboot() syscall, user processes may still be running
> concurrently and attempting to mutate sessions (e.g., adding files or
> closing sessions). To prevent this, hold the session header's rwsem and
> each session's mutex indefinitely on successful serialization.
>
> If serialization succeeds, these locks will never be released as the
> system transitions to the new kernel, effectively blocking any
> concurrent task attempting to modify or release a session. If
> liveupdate_reboot() fails, the locks are released in the error path,
> allowing normal operation to resume.
>
> Fixes: 0153094d03df ("liveupdate: luo_session: add sessions support")
> Reported-by: Oskar Gerlicz Kowalczuk <oskar@gerlicz.space>
> Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>

Reviewed-by: Pratyush Yadav (Google) <pratyush@kernel.org>

[...]

-- 
Regards,
Pratyush Yadav

Re: [PATCH v2 3/3] liveupdate: block outgoing session mutations

[Pasha Tatashin]

On 05-11 13:03, Pratyush Yadav wrote:
> On Wed, May 06 2026, Pasha Tatashin wrote:
> 
> > During the reboot() syscall, user processes may still be running
> > concurrently and attempting to mutate sessions (e.g., adding files or
> > closing sessions). To prevent this, hold the session header's rwsem and
> > each session's mutex indefinitely on successful serialization.
> >
> > If serialization succeeds, these locks will never be released as the
> > system transitions to the new kernel, effectively blocking any
> > concurrent task attempting to modify or release a session. If
> > liveupdate_reboot() fails, the locks are released in the error path,
> > allowing normal operation to resume.
> >
> > Fixes: 0153094d03df ("liveupdate: luo_session: add sessions support")
> > Reported-by: Oskar Gerlicz Kowalczuk <oskar@gerlicz.space>
> > Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
> 
> Reviewed-by: Pratyush Yadav (Google) <pratyush@kernel.org>

Sashiko also provided a good comment about this patch: We run over 
MAX_LOCK_DEPTH limit with this patch. I am going to refactor to not take 
every session lock simultaneously during serialization.

> 
> [...]
> 
> -- 
> Regards,
> Pratyush Yadav