linux-stable.git/kernel/liveupdate/luo_file.c, branch linux-rolling-stable

liveupdate: luo_file: remember retrieve() status

2026-03-19T15:15:12+00:00

commit f85b1c6af5bc3872f994df0a5688c1162de07a62 upstream.

LUO keeps track of successful retrieve attempts on a LUO file.  It does so
to avoid multiple retrievals of the same file.  Multiple retrievals cause
problems because once the file is retrieved, the serialized data
structures are likely freed and the file is likely in a very different
state from what the code expects.

The retrieve boolean in struct luo_file keeps track of this, and is passed
to the finish callback so it knows what work was already done and what it
has left to do.

All this works well when retrieve succeeds.  When it fails,
luo_retrieve_file() returns the error immediately, without ever storing
anywhere that a retrieve was attempted or what its error code was.  This
results in an errored LIVEUPDATE_SESSION_RETRIEVE_FD ioctl to userspace,
but nothing prevents it from trying this again.

The retry is problematic for much of the same reasons listed above.  The
file is likely in a very different state than what the retrieve logic
normally expects, and it might even have freed some serialization data
structures.  Attempting to access them or free them again is going to
break things.

For example, if memfd managed to restore 8 of its 10 folios, but fails on
the 9th, a subsequent retrieve attempt will try to call
kho_restore_folio() on the first folio again, and that will fail with a
warning since it is an invalid operation.

Apart from the retry, finish() also breaks.  Since on failure the
retrieved bool in luo_file is never touched, the finish() call on session
close will tell the file handler that retrieve was never attempted, and it
will try to access or free the data structures that might not exist, much
in the same way as the retry attempt.

There is no sane way of attempting the retrieve again.  Remember the error
retrieve returned and directly return it on a retry.  Also pass this
status code to finish() so it can make the right decision on the work it
needs to do.

This is done by changing the bool to an integer.  A value of 0 means
retrieve was never attempted, a positive value means it succeeded, and a
negative value means it failed and the error code is the value.

Link: https://lkml.kernel.org/r/20260216132221.987987-1-pratyush@kernel.org
Fixes: 7c722a7f44e0 ("liveupdate: luo_file: implement file systems callbacks")
Signed-off-by: Pratyush Yadav (Google) 
Reviewed-by: Mike Rapoport (Microsoft) 
Cc: Pasha Tatashin 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

liveupdate: luo_file: do not clear serialized_data on unfreeze

2026-02-03T02:43:55+00:00

Patch series "liveupdate: fixes in error handling".

This series contains some fixes in LUO's error handling paths.

The first patch deals with failed freeze() attempts.  The cleanup path
calls unfreeze, and that clears some data needed by later unpreserve
calls.

The second patch is a bit more involved.  It deals with failed retrieve()
attempts.  To do so properly, it reworks some of the error handling logic
in luo_file core.

Both these fixes are "theoretical" -- in the sense that I have not been
able to reproduce either of them in normal operation.  The only supported
file type right now is memfd, and there is nothing userspace can do right
now to make it fail its retrieve or freeze.  I need to make the retrieve
or freeze fail by artificially injecting errors.  The injected errors
trigger a use-after-free and a double-free.

That said, once more complex file handlers are added or memfd preservation
is used in ways not currently expected or covered by the tests, we will be
able to see them on real systems.


This patch (of 2):

The unfreeze operation is supposed to undo the effects of the freeze
operation.  serialized_data is not set by freeze, but by preserve. 
Consequently, the unpreserve operation needs to access serialized_data to
undo the effects of the preserve operation.  This includes freeing the
serialized data structures for example.

If a freeze callback fails, unfreeze is called for all frozen files.  This
would clear serialized_data for them.  Since live update has failed, it
can be expected that userspace aborts, releasing all sessions.  When the
sessions are released, unpreserve will be called for all files.  The
unfrozen files will see 0 in their serialized_data.  This is not expected
by file handlers, and they might either fail, leaking data and state, or
might even crash or cause invalid memory access.

Do not clear serialized_data on unfreeze so it gets passed on to
unpreserve.  There is no need to clear it on unpreserve since luo_file
will be freed immediately after.

Link: https://lkml.kernel.org/r/20260126230302.2936817-1-pratyush@kernel.org
Link: https://lkml.kernel.org/r/20260126230302.2936817-2-pratyush@kernel.org
Fixes: 7c722a7f44e0 ("liveupdate: luo_file: implement file systems callbacks")
Signed-off-by: Pratyush Yadav (Google) 
Reviewed-by: Mike Rapoport (Microsoft) 
Cc: Pasha Tatashin 
Signed-off-by: Andrew Morton

liveupdate: luo_file: don't use invalid list iterator

2025-12-11T00:07:41+00:00

If we exit a list_for_each_entry() without hitting a break then the list
iterator points to an offset from the list_head.  It's a non-NULL but
invalid pointer and dereferencing it isn't allowed.

Introduce a new "found" variable to test instead.

Link: https://lkml.kernel.org/r/aSlMc4SS09Re4_xn@stanley.mountain
Fixes: 3ee1d673194e ("liveupdate: luo_file: implement file systems callbacks")
Signed-off-by: Dan Carpenter 
Reported-by: kernel test robot 
Closes: https://lore.kernel.org/r/202511280420.y9O4fyhX-lkp@intel.com/
Reviewed-by: Mike Rapoport (Microsoft) 
Reviewed-by: Pasha Tatashin 
Cc: Pratyush Yadav 
Signed-off-by: Andrew Morton

liveupdate: luo_file: add private argument to store runtime state

2025-11-27T22:24:40+00:00

Currently file handlers only get the serialized_data field to store their
state.  This field has a pointer to the serialized state of the file, and
it becomes a part of LUO file's serialized state.

File handlers can also need some runtime state to track information that
shouldn't make it in the serialized data.

One such example is a vmalloc pointer.  While kho_preserve_vmalloc()
preserves the memory backing a vmalloc allocation, it does not store the
original vmap pointer, since that has no use being passed to the next
kernel.  The pointer is needed to free the memory in case the file is
unpreserved.

Provide a private field in struct luo_file and pass it to all the
callbacks.  The field's can be set by preserve, and must be freed by
unpreserve.

Link: https://lkml.kernel.org/r/20251125165850.3389713-14-pasha.tatashin@soleen.com
Signed-off-by: Pratyush Yadav 
Co-developed-by: Pasha Tatashin 
Signed-off-by: Pasha Tatashin 
Reviewed-by: Mike Rapoport (Microsoft) 
Tested-by: David Matlack 
Cc: Aleksander Lobakin 
Cc: Alexander Graf 
Cc: Alice Ryhl 
Cc: Andriy Shevchenko 
Cc: anish kumar 
Cc: Anna Schumaker 
Cc: Bartosz Golaszewski 
Cc: Bjorn Helgaas 
Cc: Borislav Betkov 
Cc: Chanwoo Choi 
Cc: Chen Ridong 
Cc: Chris Li 
Cc: Christian Brauner 
Cc: Daniel Wagner 
Cc: Danilo Krummrich 
Cc: Dan Williams 
Cc: David Hildenbrand 
Cc: David Jeffery 
Cc: David Rientjes 
Cc: Greg Kroah-Hartman 
Cc: Guixin Liu 
Cc: "H. Peter Anvin" 
Cc: Hugh Dickins 
Cc: Ilpo Järvinen 
Cc: Ingo Molnar 
Cc: Ira Weiny 
Cc: Jann Horn 
Cc: Jason Gunthorpe 
Cc: Jens Axboe 
Cc: Joanthan Cameron 
Cc: Joel Granados 
Cc: Johannes Weiner 
Cc: Jonathan Corbet 
Cc: Lennart Poettering 
Cc: Leon Romanovsky 
Cc: Leon Romanovsky 
Cc: Lukas Wunner 
Cc: Marc Rutland 
Cc: Masahiro Yamada 
Cc: Matthew Maurer 
Cc: Miguel Ojeda 
Cc: Myugnjoo Ham 
Cc: Parav Pandit 
Cc: Pratyush Yadav 
Cc: Randy Dunlap 
Cc: Roman Gushchin 
Cc: Saeed Mahameed 
Cc: Samiullah Khawaja 
Cc: Song Liu 
Cc: Steven Rostedt 
Cc: Stuart Hayes 
Cc: Tejun Heo 
Cc: Thomas Gleinxer 
Cc: Thomas Weißschuh 
Cc: Vincent Guittot 
Cc: William Tu 
Cc: Yoann Congal 
Cc: Zhu Yanjun 
Cc: Zijun Hu 
Signed-off-by: Andrew Morton

liveupdate: luo_file: implement file systems callbacks

2025-11-27T22:24:38+00:00

This patch implements the core mechanism for managing preserved files
throughout the live update lifecycle.  It provides the logic to invoke the
file handler callbacks (preserve, unpreserve, freeze, unfreeze, retrieve,
and finish) at the appropriate stages.

During the reboot phase, luo_file_freeze() serializes the final metadata
for each file (handler compatible string, token, and data handle) into a
memory region preserved by KHO.  In the new kernel, luo_file_deserialize()
reconstructs the in-memory file list from this data, preparing the session
for retrieval.

Link: https://lkml.kernel.org/r/20251125165850.3389713-7-pasha.tatashin@soleen.com
Signed-off-by: Pasha Tatashin 
Reviewed-by: Mike Rapoport (Microsoft) 
Reviewed-by: Pratyush Yadav 
Tested-by: David Matlack 
Cc: Aleksander Lobakin 
Cc: Alexander Graf 
Cc: Alice Ryhl 
Cc: Andriy Shevchenko 
Cc: anish kumar 
Cc: Anna Schumaker 
Cc: Bartosz Golaszewski 
Cc: Bjorn Helgaas 
Cc: Borislav Betkov 
Cc: Chanwoo Choi 
Cc: Chen Ridong 
Cc: Chris Li 
Cc: Christian Brauner 
Cc: Daniel Wagner 
Cc: Danilo Krummrich 
Cc: Dan Williams 
Cc: David Hildenbrand 
Cc: David Jeffery 
Cc: David Rientjes 
Cc: Greg Kroah-Hartman 
Cc: Guixin Liu 
Cc: "H. Peter Anvin" 
Cc: Hugh Dickins 
Cc: Ilpo Järvinen 
Cc: Ingo Molnar 
Cc: Ira Weiny 
Cc: Jann Horn 
Cc: Jason Gunthorpe 
Cc: Jens Axboe 
Cc: Joanthan Cameron 
Cc: Joel Granados 
Cc: Johannes Weiner 
Cc: Jonathan Corbet 
Cc: Lennart Poettering 
Cc: Leon Romanovsky 
Cc: Leon Romanovsky 
Cc: Lukas Wunner 
Cc: Marc Rutland 
Cc: Masahiro Yamada 
Cc: Matthew Maurer 
Cc: Miguel Ojeda 
Cc: Myugnjoo Ham 
Cc: Parav Pandit 
Cc: Pratyush Yadav 
Cc: Randy Dunlap 
Cc: Roman Gushchin 
Cc: Saeed Mahameed 
Cc: Samiullah Khawaja 
Cc: Song Liu 
Cc: Steven Rostedt 
Cc: Stuart Hayes 
Cc: Tejun Heo 
Cc: Thomas Gleinxer 
Cc: Thomas Weißschuh 
Cc: Vincent Guittot 
Cc: William Tu 
Cc: Yoann Congal 
Cc: Zhu Yanjun 
Cc: Zijun Hu 
Signed-off-by: Andrew Morton