linux-api.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pasha Tatashin <pasha.tatashin@soleen.com>
To: Mike Rapoport <rppt@kernel.org>
Cc: pratyush@kernel.org, jasonmiu@google.com, graf@amazon.com,
	 dmatlack@google.com, rientjes@google.com, corbet@lwn.net,
	 rdunlap@infradead.org, ilpo.jarvinen@linux.intel.com,
	kanie@linux.alibaba.com,  ojeda@kernel.org, aliceryhl@google.com,
	masahiroy@kernel.org,  akpm@linux-foundation.org, tj@kernel.org,
	yoann.congal@smile.fr,  mmaurer@google.com,
	roman.gushchin@linux.dev, chenridong@huawei.com,
	 axboe@kernel.dk, mark.rutland@arm.com, jannh@google.com,
	 vincent.guittot@linaro.org, hannes@cmpxchg.org,
	dan.j.williams@intel.com,  david@redhat.com,
	joel.granados@kernel.org, rostedt@goodmis.org,
	 anna.schumaker@oracle.com, song@kernel.org,
	linux@weissschuh.net,  linux-kernel@vger.kernel.org,
	linux-doc@vger.kernel.org, linux-mm@kvack.org,
	 gregkh@linuxfoundation.org, tglx@linutronix.de,
	mingo@redhat.com,  bp@alien8.de, dave.hansen@linux.intel.com,
	x86@kernel.org, hpa@zytor.com,  rafael@kernel.org,
	dakr@kernel.org, bartosz.golaszewski@linaro.org,
	 cw00.choi@samsung.com, myungjoo.ham@samsung.com,
	yesanishhere@gmail.com,  Jonathan.Cameron@huawei.com,
	quic_zijuhu@quicinc.com,  aleksander.lobakin@intel.com,
	ira.weiny@intel.com,  andriy.shevchenko@linux.intel.com,
	leon@kernel.org, lukas@wunner.de,  bhelgaas@google.com,
	wagi@kernel.org, djeffery@redhat.com,  stuart.w.hayes@gmail.com,
	ptyadav@amazon.de, lennart@poettering.net,  brauner@kernel.org,
	linux-api@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	 saeedm@nvidia.com, ajayachandra@nvidia.com, jgg@nvidia.com,
	parav@nvidia.com,  leonro@nvidia.com, witu@nvidia.com,
	hughd@google.com, skhawaja@google.com,  chrisl@kernel.org
Subject: Re: [PATCH v6 04/20] liveupdate: luo_session: add sessions support
Date: Mon, 17 Nov 2025 10:09:28 -0500	[thread overview]
Message-ID: <CA+CK2bC_z_6hgYu_qB7cBK2LrBSs8grjw7HCC+QrtUSrFuN5ZQ@mail.gmail.com> (raw)
In-Reply-To: <aRoEduya5EO8Xc1b@kernel.org>

> > +/**
> > + * struct luo_session_ser - Represents the serialized metadata for a LUO session.
> > + * @name:    The unique name of the session, copied from the `luo_session`
> > + *           structure.
>
> I'd phase it as
>
>                 The unique name of the session provided by the userspace at
>                 the time of session creation.

Done

>
> > + * @files:   The physical address of a contiguous memory block that holds
> > + *           the serialized state of files.
>
> Maybe add                                    ^ in this session?

Done

>
> > + * @pgcnt:   The number of pages occupied by the `files` memory block.
> > + * @count:   The total number of files that were part of this session during
> > + *           serialization. Used for iteration and validation during
> > + *           restoration.
> > + *
> > + * This structure is used to package session-specific metadata for transfer
> > + * between kernels via Kexec Handover. An array of these structures (one per
> > + * session) is created and passed to the new kernel, allowing it to reconstruct
> > + * the session context.
> > + *
> > + * If this structure is modified, LUO_SESSION_COMPATIBLE must be updated.
>
> This comment applies to the luo_session_header_ser description as well.

Done

>
> > + */
> > +struct luo_session_ser {
> > +     char name[LIVEUPDATE_SESSION_NAME_LENGTH];
> > +     u64 files;
> > +     u64 pgcnt;
> > +     u64 count;
> > +} __packed;
> > +
> >  #endif /* _LINUX_LIVEUPDATE_ABI_LUO_H */
> > diff --git a/include/uapi/linux/liveupdate.h b/include/uapi/linux/liveupdate.h
> > index df34c1642c4d..d2ef2f7e0dbd 100644
> > --- a/include/uapi/linux/liveupdate.h
> > +++ b/include/uapi/linux/liveupdate.h
> > @@ -43,4 +43,7 @@
> >  /* The ioctl type, documented in ioctl-number.rst */
> >  #define LIVEUPDATE_IOCTL_TYPE                0xBA
> >
> > +/* The maximum length of session name including null termination */
> > +#define LIVEUPDATE_SESSION_NAME_LENGTH 56
>
> You decided not to bump it to 64 in the end? ;-)

I bumped it to 64, but in the next patch, I will fix it in the next version.

>
> > +
> >  #endif /* _UAPI_LIVEUPDATE_H */
> > diff --git a/kernel/liveupdate/Makefile b/kernel/liveupdate/Makefile
> > index 413722002b7a..83285e7ad726 100644
> > --- a/kernel/liveupdate/Makefile
> > +++ b/kernel/liveupdate/Makefile
> > @@ -2,7 +2,8 @@
> >
> >  luo-y :=                                                             \
> >               luo_core.o                                              \
> > -             luo_ioctl.o
> > +             luo_ioctl.o                                             \
> > +             luo_session.o
> >
> >  obj-$(CONFIG_KEXEC_HANDOVER)         += kexec_handover.o
> >  obj-$(CONFIG_KEXEC_HANDOVER_DEBUG)   += kexec_handover_debug.o
>
> ...
>
> > +int luo_session_retrieve(const char *name, struct file **filep)
> > +{
> > +     struct luo_session_header *sh = &luo_session_global.incoming;
> > +     struct luo_session *session = NULL;
> > +     struct luo_session *it;
> > +     int err;
> > +
> > +     scoped_guard(rwsem_read, &sh->rwsem) {
> > +             list_for_each_entry(it, &sh->list, list) {
> > +                     if (!strncmp(it->name, name, sizeof(it->name))) {
> > +                             session = it;
> > +                             break;
> > +                     }
> > +             }
> > +     }
> > +
> > +     if (!session)
> > +             return -ENOENT;
> > +
> > +     scoped_guard(mutex, &session->mutex) {
> > +             if (session->retrieved)
> > +                     return -EINVAL;
> > +     }
> > +
> > +     err = luo_session_getfile(session, filep);
> > +     if (!err) {
> > +             scoped_guard(mutex, &session->mutex)
> > +                     session->retrieved = true;
>
> Retaking the mutex here seems a bit odd.
> Do we really have to lock session->mutex in luo_session_getfile()?

Moved it out of luo_session_getfile(), and added
lockdep_assert_held(&session->mutex); to luo_session_getfile


> > +int luo_session_deserialize(void)
> > +{
> > +     struct luo_session_header *sh = &luo_session_global.incoming;
> > +     int err;
> > +
> > +     if (luo_session_is_deserialized())
> > +             return 0;
> > +
> > +     luo_session_global.deserialized = true;
> > +     if (!sh->active) {
> > +             INIT_LIST_HEAD(&sh->list);
> > +             init_rwsem(&sh->rwsem);
> > +             return 0;
>
> How this can happen? luo_session_deserialize() is supposed to be called
> from ioctl and luo_session_global.incoming should be set up way earlier.

No LUO was passed from the previous kernel, so
luo_session_global.incoming.active stays false, as it is not
participating.

> And, why don't we initialize ->list and ->rwsem statically?

Good idea, done.

> > +     }
> > +
> > +     for (int i = 0; i < sh->header_ser->count; i++) {
> > +             struct luo_session *session;
> > +
> > +             session = luo_session_alloc(sh->ser[i].name);
> > +             if (IS_ERR(session)) {
> > +                     pr_warn("Failed to allocate session [%s] during deserialization %pe\n",
> > +                             sh->ser[i].name, session);
> > +                     return PTR_ERR(session);
> > +             }
>
> The allocated sessions still need to be freed if an insert fails ;-)

No. We have failed to deserialize, so anyways the machine will need to
be rebooted by the user in order to release the preserved resources.

This is something that Jason Gunthrope also mentioned regarding IOMMU:
if something is not correct (i.e., if a session cannot finish for some
reason), don't add complicated "undo" code that cleans up all
resources. Instead, treat them as a memory leak and allow a reboot to
perform the cleanup.

While in this particular patch the clean-up looks simple, later in the
series we are adding file deserialization to each session to this
function. So, the clean-up will look like this: we would have to free
the resources for each session we deserialized, and also free the
resources for files that were deserialized for those sessions, only to
still boot into a "maintenance" mode where bunch of resources are not
accessible from which the machine would have to be rebooted to get
back to a normal state. This code will never be tested, and never be
used, so let's use reboot to solve this problem, where devices are
going to be properly reset, and memory is going to be properly freed.

  reply	other threads:[~2025-11-17 15:10 UTC|newest]

Thread overview: 99+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-15 23:33 [PATCH v6 00/20] Live Update Orchestrator Pasha Tatashin
2025-11-15 23:33 ` [PATCH v6 01/20] liveupdate: luo_core: luo_ioctl: " Pasha Tatashin
2025-11-17  2:54   ` Andrew Morton
2025-11-17 14:27     ` Pasha Tatashin
2025-11-18 15:45   ` Pratyush Yadav
2025-11-18 16:11     ` Pasha Tatashin
2025-11-15 23:33 ` [PATCH v6 02/20] liveupdate: luo_core: integrate with KHO Pasha Tatashin
2025-11-16 12:43   ` Mike Rapoport
2025-11-16 14:55     ` Pasha Tatashin
2025-11-16 19:16       ` Mike Rapoport
2025-11-17 18:29         ` Pasha Tatashin
2025-11-17 21:05           ` Mike Rapoport
2025-11-18  4:22             ` Pasha Tatashin
2025-11-18 11:21               ` Mike Rapoport
2025-11-18 14:03                 ` Jason Gunthorpe
2025-11-18 15:06                   ` Mike Rapoport
2025-11-18 15:18                     ` Pasha Tatashin
2025-11-18 15:36                       ` Jason Gunthorpe
2025-11-18 15:46                         ` Pasha Tatashin
2025-11-18 16:15                           ` Jason Gunthorpe
2025-11-18 22:07                             ` Pasha Tatashin
2025-11-18 23:25                               ` Jason Gunthorpe
2025-11-19  3:03                                 ` Pasha Tatashin
2025-11-15 23:33 ` [PATCH v6 03/20] kexec: call liveupdate_reboot() before kexec Pasha Tatashin
2025-11-16 12:44   ` Mike Rapoport
2025-11-15 23:33 ` [PATCH v6 04/20] liveupdate: luo_session: add sessions support Pasha Tatashin
2025-11-16 17:05   ` Mike Rapoport
2025-11-17 15:09     ` Pasha Tatashin [this message]
2025-11-17 21:11       ` Mike Rapoport
2025-11-18  4:28         ` Pasha Tatashin
2025-11-15 23:33 ` [PATCH v6 05/20] liveupdate: luo_ioctl: add user interface Pasha Tatashin
2025-11-16 17:15   ` Mike Rapoport
2025-11-17 14:22     ` Pasha Tatashin
2025-11-20 18:37   ` David Matlack
2025-11-20 19:22     ` Pasha Tatashin
2025-11-20 19:42       ` David Matlack
2025-11-20 20:13         ` Pasha Tatashin
2025-11-15 23:33 ` [PATCH v6 06/20] liveupdate: luo_file: implement file systems callbacks Pasha Tatashin
2025-11-16 18:15   ` Mike Rapoport
2025-11-17 17:50     ` Pasha Tatashin
2025-11-20 17:20       ` Mike Rapoport
2025-11-20 20:25         ` Pasha Tatashin
2025-11-18 17:38   ` David Matlack
2025-11-18 17:43     ` Pratyush Yadav
2025-11-18 17:58       ` Pasha Tatashin
2025-11-18 18:17         ` Pratyush Yadav
2025-11-18 19:09         ` Jason Gunthorpe
2025-11-18 19:31           ` Pasha Tatashin
2025-11-15 23:33 ` [PATCH v6 07/20] liveupdate: luo_session: Add ioctls for file preservation Pasha Tatashin
2025-11-16 18:25   ` Mike Rapoport
2025-11-18  2:58     ` Pasha Tatashin
2025-11-15 23:33 ` [PATCH v6 08/20] liveupdate: luo_flb: Introduce File-Lifecycle-Bound global state Pasha Tatashin
2025-11-17  9:39   ` Mike Rapoport
2025-11-18  3:54     ` Pasha Tatashin
2025-11-18 11:28       ` Mike Rapoport
2025-11-18 15:37         ` Pasha Tatashin
2025-11-20 18:50           ` Mike Rapoport
2025-11-20 19:10             ` Pasha Tatashin
2025-11-15 23:33 ` [PATCH v6 09/20] docs: add luo documentation Pasha Tatashin
2025-11-15 23:33 ` [PATCH v6 10/20] MAINTAINERS: add liveupdate entry Pasha Tatashin
2025-11-17  9:40   ` Mike Rapoport
2025-11-17 18:20     ` Pasha Tatashin
2025-11-15 23:33 ` [PATCH v6 11/20] mm: shmem: use SHMEM_F_* flags instead of VM_* flags Pasha Tatashin
2025-11-17  9:48   ` Mike Rapoport
2025-11-17 18:25     ` Pasha Tatashin
2025-11-15 23:33 ` [PATCH v6 12/20] mm: shmem: allow freezing inode mapping Pasha Tatashin
2025-11-17 10:08   ` Mike Rapoport
2025-11-18  4:13     ` Pasha Tatashin
2025-11-15 23:33 ` [PATCH v6 13/20] mm: shmem: export some functions to internal.h Pasha Tatashin
2025-11-17 10:14   ` Mike Rapoport
2025-11-17 18:43     ` Pasha Tatashin
2025-11-15 23:34 ` [PATCH v6 14/20] liveupdate: luo_file: add private argument to store runtime state Pasha Tatashin
2025-11-17 10:15   ` Mike Rapoport
2025-11-17 18:45     ` Pasha Tatashin
2025-11-15 23:34 ` [PATCH v6 15/20] mm: memfd_luo: allow preserving memfd Pasha Tatashin
2025-11-17 11:03   ` Mike Rapoport
2025-11-19 21:56     ` Pasha Tatashin
2025-11-20 15:34       ` Pratyush Yadav
2025-11-15 23:34 ` [PATCH v6 16/20] docs: add documentation for memfd preservation via LUO Pasha Tatashin
2025-11-15 23:34 ` [PATCH v6 17/20] selftests/liveupdate: Add userspace API selftests Pasha Tatashin
2025-11-17 19:38   ` David Matlack
2025-11-17 20:16     ` Pasha Tatashin
2025-11-15 23:34 ` [PATCH v6 18/20] selftests/liveupdate: Add kexec-based selftest for session lifecycle Pasha Tatashin
2025-11-16 18:53   ` Zhu Yanjun
2025-11-17 18:23     ` Pasha Tatashin
2025-11-17 19:27   ` David Matlack
2025-11-17 20:08     ` David Matlack
2025-11-17 21:06       ` David Matlack
2025-11-18  1:01         ` Pasha Tatashin
2025-11-18  0:06   ` David Matlack
2025-11-18  1:08     ` Pasha Tatashin
2025-11-19 21:20   ` David Matlack
2025-11-19 22:12     ` Pasha Tatashin
2025-11-15 23:34 ` [PATCH v6 19/20] selftests/liveupdate: Add kexec test for multiple and empty sessions Pasha Tatashin
2025-11-15 23:34 ` [PATCH v6 20/20] tests/liveupdate: Add in-kernel liveupdate test Pasha Tatashin
2025-11-17 11:13   ` Mike Rapoport
2025-11-17 19:00     ` Pasha Tatashin
2025-11-18 11:30       ` Mike Rapoport
2025-11-18 18:56         ` Pasha Tatashin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CA+CK2bC_z_6hgYu_qB7cBK2LrBSs8grjw7HCC+QrtUSrFuN5ZQ@mail.gmail.com \
    --to=pasha.tatashin@soleen.com \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=ajayachandra@nvidia.com \
    --cc=akpm@linux-foundation.org \
    --cc=aleksander.lobakin@intel.com \
    --cc=aliceryhl@google.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=anna.schumaker@oracle.com \
    --cc=axboe@kernel.dk \
    --cc=bartosz.golaszewski@linaro.org \
    --cc=bhelgaas@google.com \
    --cc=bp@alien8.de \
    --cc=brauner@kernel.org \
    --cc=chenridong@huawei.com \
    --cc=chrisl@kernel.org \
    --cc=corbet@lwn.net \
    --cc=cw00.choi@samsung.com \
    --cc=dakr@kernel.org \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=david@redhat.com \
    --cc=djeffery@redhat.com \
    --cc=dmatlack@google.com \
    --cc=graf@amazon.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=hpa@zytor.com \
    --cc=hughd@google.com \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=ira.weiny@intel.com \
    --cc=jannh@google.com \
    --cc=jasonmiu@google.com \
    --cc=jgg@nvidia.com \
    --cc=joel.granados@kernel.org \
    --cc=kanie@linux.alibaba.com \
    --cc=lennart@poettering.net \
    --cc=leon@kernel.org \
    --cc=leonro@nvidia.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux@weissschuh.net \
    --cc=lukas@wunner.de \
    --cc=mark.rutland@arm.com \
    --cc=masahiroy@kernel.org \
    --cc=mingo@redhat.com \
    --cc=mmaurer@google.com \
    --cc=myungjoo.ham@samsung.com \
    --cc=ojeda@kernel.org \
    --cc=parav@nvidia.com \
    --cc=pratyush@kernel.org \
    --cc=ptyadav@amazon.de \
    --cc=quic_zijuhu@quicinc.com \
    --cc=rafael@kernel.org \
    --cc=rdunlap@infradead.org \
    --cc=rientjes@google.com \
    --cc=roman.gushchin@linux.dev \
    --cc=rostedt@goodmis.org \
    --cc=rppt@kernel.org \
    --cc=saeedm@nvidia.com \
    --cc=skhawaja@google.com \
    --cc=song@kernel.org \
    --cc=stuart.w.hayes@gmail.com \
    --cc=tglx@linutronix.de \
    --cc=tj@kernel.org \
    --cc=vincent.guittot@linaro.org \
    --cc=wagi@kernel.org \
    --cc=witu@nvidia.com \
    --cc=x86@kernel.org \
    --cc=yesanishhere@gmail.com \
    --cc=yoann.congal@smile.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).