| Message ID | 20260610064812.4010511-2-amikan@ilbers.de |
|---|---|
| State | Under Review |
| Headers | show |
| Series | Rootfs install race fix for isar-apt packages | expand |
On Wed, 2026-06-10 at 09:48 +0300, Anton Mikanovich wrote: > In some cases only one command from all the ROOTFS_INSTALL_COMMAND list > can require isar-apt locking. To allow this logic improve flag checking > to accept the list of codenames. Existing API and codenames > ("acquire-before" and "release-after") were not changed. > > So the usage of single task declaration now looks like: > > rootfs_install_cmd[isar-apt-lock] = "acquire-before release-after" Hi, does it even make sense to do an acquire release in two different commands? To me this looks like a source for deadlocks. Felix > > Signed-off-by: Anton Mikanovich <amikan@ilbers.de> > --- > meta/classes-recipe/rootfs.bbclass | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/meta/classes-recipe/rootfs.bbclass b/meta/classes-recipe/rootfs.bbclass > index 8b502a50..dc4e702c 100644 > --- a/meta/classes-recipe/rootfs.bbclass > +++ b/meta/classes-recipe/rootfs.bbclass > @@ -427,13 +427,13 @@ python do_rootfs_install() { > for cmd in cmds: > progress_reporter.next_stage() > > - if (d.getVarFlag(cmd, 'isar-apt-lock') or "") == "acquire-before": > + if "acquire-before" in (d.getVarFlag(cmd, 'isar-apt-lock') or ""): > lock = bb.utils.lockfile(d.getVar("REPO_ISAR_DIR") + "/isar.lock", > shared=True) > > bb.build.exec_func(cmd, d) > > - if (d.getVarFlag(cmd, 'isar-apt-lock') or "") == "release-after": > + if "release-after" in (d.getVarFlag(cmd, 'isar-apt-lock') or ""): > bb.utils.unlockfile(lock) > progress_reporter.finish() > finally: > -- > 2.34.1 > > -- > 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/20260610064812.4010511-2-amikan%40ilbers.de.
10.06.2026 11:23, MOESSBAUER, Felix wrote: > On Wed, 2026-06-10 at 09:48 +0300, Anton Mikanovich wrote: >> In some cases only one command from all the ROOTFS_INSTALL_COMMAND list >> can require isar-apt locking. To allow this logic improve flag checking >> to accept the list of codenames. Existing API and codenames >> ("acquire-before" and "release-after") were not changed. >> >> So the usage of single task declaration now looks like: >> >> rootfs_install_cmd[isar-apt-lock] = "acquire-before release-after" > Hi, does it even make sense to do an acquire release in two different > commands? To me this looks like a source for deadlocks. > > Felix Current implementation have 4 tasks combined in one lock section. This is done to be sure isar-apt will not changed between "apt-get update" and "apt-get install" commands. This probably can be reordered and optimized, but it will be out of scope for the current patchset.
On Thu, 2026-06-11 at 10:01 +0300, Anton Mikanovich wrote: > 10.06.2026 11:23, MOESSBAUER, Felix wrote: > > On Wed, 2026-06-10 at 09:48 +0300, Anton Mikanovich wrote: > > > In some cases only one command from all the ROOTFS_INSTALL_COMMAND list > > > can require isar-apt locking. To allow this logic improve flag checking > > > to accept the list of codenames. Existing API and codenames > > > ("acquire-before" and "release-after") were not changed. > > > > > > So the usage of single task declaration now looks like: > > > > > > rootfs_install_cmd[isar-apt-lock] = "acquire-before release-after" > > Hi, does it even make sense to do an acquire release in two different > > commands? To me this looks like a source for deadlocks. > > > > Felix > Current implementation have 4 tasks combined in one lock section. > This is done to be sure isar-apt will not changed between "apt-get update" > and "apt-get install" commands. This probably can be reordered and > optimized, > but it will be out of scope for the current patchset. Makes sense. Then the patchset is fine. Reviewed-by: Felix Moessbauer <felix.moessbauer@siemens.com>
diff --git a/meta/classes-recipe/rootfs.bbclass b/meta/classes-recipe/rootfs.bbclass index 8b502a50..dc4e702c 100644 --- a/meta/classes-recipe/rootfs.bbclass +++ b/meta/classes-recipe/rootfs.bbclass @@ -427,13 +427,13 @@ python do_rootfs_install() { for cmd in cmds: progress_reporter.next_stage() - if (d.getVarFlag(cmd, 'isar-apt-lock') or "") == "acquire-before": + if "acquire-before" in (d.getVarFlag(cmd, 'isar-apt-lock') or ""): lock = bb.utils.lockfile(d.getVar("REPO_ISAR_DIR") + "/isar.lock", shared=True) bb.build.exec_func(cmd, d) - if (d.getVarFlag(cmd, 'isar-apt-lock') or "") == "release-after": + if "release-after" in (d.getVarFlag(cmd, 'isar-apt-lock') or ""): bb.utils.unlockfile(lock) progress_reporter.finish() finally:
In some cases only one command from all the ROOTFS_INSTALL_COMMAND list can require isar-apt locking. To allow this logic improve flag checking to accept the list of codenames. Existing API and codenames ("acquire-before" and "release-after") were not changed. So the usage of single task declaration now looks like: rootfs_install_cmd[isar-apt-lock] = "acquire-before release-after" Signed-off-by: Anton Mikanovich <amikan@ilbers.de> --- meta/classes-recipe/rootfs.bbclass | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)