public inbox for isar-users@googlegroups.com
 help / color / mirror / Atom feed
From: "'Felix Moessbauer' via isar-users" <isar-users@googlegroups.com>
To: isar-users@googlegroups.com
Cc: adriaan.schmidt@siemens.com,
	Felix Moessbauer <felix.moessbauer@siemens.com>
Subject: [PATCH 2/2] sstate: guard sstate funcs against execution in wrong context
Date: Thu, 25 Jun 2026 17:02:32 +0200	[thread overview]
Message-ID: <20260625150232.531442-3-felix.moessbauer@siemens.com> (raw)
In-Reply-To: <20260625150232.531442-1-felix.moessbauer@siemens.com>

In sstate.bbclass, sstate_package() sets SSTATE_CURRTASK from
the sstate task being packaged, then runs every function listed
in SSTATECREATEFUNCS. This happens independent of the context the sstate
task is scoped to for all tasks in a single recipe.

While this pattern is not problematic in isar itself (we only have one
SSTATECREATEFUNC per recipe), it becomes problematic when downstream
users define further manual sstate tasks. In this case, the sstate tasks
are executed in the wrong context, leading to races and failures in all
colors.

We fix this by guarding each manually defined sstate func to only run in
its intended context.

Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com>
---
 meta/classes-recipe/dpkg-base.bbclass                 | 4 ++++
 meta/classes-recipe/rootfs.bbclass                    | 4 ++++
 meta/recipes-core/isar-mmdebstrap/isar-mmdebstrap.inc | 4 ++++
 3 files changed, 12 insertions(+)

diff --git a/meta/classes-recipe/dpkg-base.bbclass b/meta/classes-recipe/dpkg-base.bbclass
index f7a12302..85c37a5a 100644
--- a/meta/classes-recipe/dpkg-base.bbclass
+++ b/meta/classes-recipe/dpkg-base.bbclass
@@ -184,6 +184,8 @@ SSTATECREATEFUNCS += "dpkg_build_sstate_prepare"
 SSTATEPOSTINSTFUNCS += "dpkg_build_sstate_finalize"
 
 dpkg_build_sstate_prepare() {
+    [ "${SSTATE_CURRTASK}" = "dpkg_build" ] || return 0
+
     # this runs in SSTATE_BUILDDIR, which will be deleted automatically
     if [ -n "$(find ${WORKDIR} -maxdepth 1 -name '*.deb' -print -quit)" ]; then
         cp -f ${WORKDIR}/*.deb -t .
@@ -191,6 +193,8 @@ dpkg_build_sstate_prepare() {
 }
 
 dpkg_build_sstate_finalize() {
+    [ "${SSTATE_CURRTASK}" = "dpkg_build" ] || return 0
+
     # this runs in SSTATE_INSTDIR
     if [ -n "$(find . -maxdepth 1 -name '*.deb' -print -quit)" ]; then
         mv -f ./*.deb -t ${WORKDIR}/
diff --git a/meta/classes-recipe/rootfs.bbclass b/meta/classes-recipe/rootfs.bbclass
index 8a4aad16..936f56fe 100644
--- a/meta/classes-recipe/rootfs.bbclass
+++ b/meta/classes-recipe/rootfs.bbclass
@@ -691,6 +691,8 @@ SSTATE_TAR_ATTR_FLAGS ?= "--xattrs --xattrs-include='*'"
 
 # the rootfs is owned by root, so we need some sudoing to pack and unpack
 rootfs_install_sstate_prepare() {
+    [ "${SSTATE_CURRTASK}" = "rootfs_install" ] || return 0
+
     # this runs in SSTATE_BUILDDIR, which will be deleted automatically
     # tar --one-file-system will cross bind-mounts to the same filesystem,
     # so we use some mount magic to prevent that
@@ -705,6 +707,8 @@ rootfs_install_sstate_prepare() {
 rootfs_install_sstate_prepare[lockfiles] = "${REPO_ISAR_DIR}/isar.lock"
 
 rootfs_install_sstate_finalize() {
+    [ "${SSTATE_CURRTASK}" = "rootfs_install" ] || return 0
+
     # this runs in SSTATE_INSTDIR
     # - after building the rootfs, the tar won't be there, but we also don't need to unpack
     # - after restoring from cache, there will be a tar which we unpack and then delete
diff --git a/meta/recipes-core/isar-mmdebstrap/isar-mmdebstrap.inc b/meta/recipes-core/isar-mmdebstrap/isar-mmdebstrap.inc
index e746f469..98f6c090 100644
--- a/meta/recipes-core/isar-mmdebstrap/isar-mmdebstrap.inc
+++ b/meta/recipes-core/isar-mmdebstrap/isar-mmdebstrap.inc
@@ -264,12 +264,16 @@ SSTATECREATEFUNCS += "bootstrap_sstate_prepare"
 SSTATEPOSTINSTFUNCS += "bootstrap_sstate_finalize"
 
 bootstrap_sstate_prepare() {
+    [ "${SSTATE_CURRTASK}" = "bootstrap" ] || return 0
+
     # this runs in SSTATE_BUILDDIR, which will be deleted automatically
     sudo cp -a "${WORKDIR}/rootfs.tar.zst" ./bootstrap.tar.zst
     sudo chown $(id -u):$(id -g) bootstrap.tar.zst
 }
 
 bootstrap_sstate_finalize() {
+    [ "${SSTATE_CURRTASK}" = "bootstrap" ] || return 0
+
     # this runs in SSTATE_INSTDIR
     # we should restore symlinks after using tar
     if [ -f bootstrap.tar.zst ]; then
-- 
2.53.0

-- 
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/isar-users/20260625150232.531442-3-felix.moessbauer%40siemens.com.

  parent reply	other threads:[~2026-06-25 15:02 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-25 15:02 [PATCH 0/2] Fix data races in sstate tasks 'Felix Moessbauer' via isar-users
2026-06-25 15:02 ` [PATCH 1/2] fix(rootfs): protect rootfs_install sstate prepare with lock 'Felix Moessbauer' via isar-users
2026-06-25 15:02 ` 'Felix Moessbauer' via isar-users [this message]
2026-06-25 16:43   ` [PATCH 2/2] sstate: guard sstate funcs against execution in wrong context 'Jan Kiszka' via isar-users
2026-06-25 22:16     ` 'MOESSBAUER, Felix' via isar-users
2026-07-01  9:06 ` [PATCH 0/2] Fix data races in sstate tasks Zhihang Wei

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=20260625150232.531442-3-felix.moessbauer@siemens.com \
    --to=isar-users@googlegroups.com \
    --cc=adriaan.schmidt@siemens.com \
    --cc=felix.moessbauer@siemens.com \
    /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