From: Anton Mikanovich <amikan@ilbers.de>
To: Jan Kiszka <jan.kiszka@siemens.com>,
"Moessbauer, Felix" <felix.moessbauer@siemens.com>,
"isar-users@googlegroups.com" <isar-users@googlegroups.com>,
Baurzhan Ismagulov <ibr@ilbers.de>
Cc: "henning.schild@siemens.com" <henning.schild@siemens.com>
Subject: Re: [PATCH] mount: Cleanup reference counters before build
Date: Mon, 5 Jul 2021 17:30:35 +0300 [thread overview]
Message-ID: <6574c75e-c25b-8060-3f26-681ef842b995@ilbers.de> (raw)
In-Reply-To: <e7a5fa6e-d7b3-9252-b8c0-36559290d95f@siemens.com>
29.06.2021 16:49, Jan Kiszka wrote:
> We need a clearer picture what it fixes, what it possibly can't fix (I
> doubt it can fix all error cases), and if we still want it then. Maybe
> start with documenting the API changes and their reasoning.
>
> Also describe more clearly how to reproduce the issues you were seeing
> and trying to fix. That is key to understand if the new solution is
> actually a solution or just shifting the problem from left to right.
To reproduce the original issue (fixed by `Rebuild mount logic`
patchset), a task running twice for two targets (linux-mainline in our
case) should fail, the second task run should start and succeed:
To have the original issue fixed by `Rebuild mount logic` patchset be
reproduced you need one recipe to be included into two targets, and this
recipe should also failed on the first build attempt, but succeed on
second one. Moreover, this issue will be reproduced only in case the
second run will start directly after the fail:
>bitbake mc:de0-nano-soc-buster:isar-image-base
mc:stm32mp15x-buster:isar-image-base
>...
>ERROR: Logfile of failure stored in:
/opt/isar/build/tmp/work/debian-buster-armhf/linux-mainline/5.4.70-r0/temp/log.do_dpkg_build.12459
>NOTE: recipe linux-mainline-5.4.70-r0: task do_dpkg_build: Failed
>ERROR: Task
(mc:stm32mp15x-buster:/opt/isar/meta-isar/recipes-kernel/linux/linux-mainline_5.4.70.bb:do_dpkg_build)
failed with exit code '1'
>NOTE: Running task 304 of 350
(mc:de0-nano-soc-buster:/opt/isar/meta-isar/recipes-kernel/linux/linux-mainline_5.4.70.bb:do_dpkg_build)
>NOTE: recipe linux-mainline-5.4.70-r0: task do_dpkg_build: Started
>WARNING: mc:de0-nano-soc-buster:linux-mainline-5.4.70-r0
do_dpkg_build:
/opt/isar/build/tmp/deploy/buildchroot-target/debian-buster-armhf//home/builder/linux-mainline:
Couldn't unmount, retrying...
In most cases second one does not start and bitbake exit due to the
error, but when it start the build is went to the infinite loop.
In that scenario:
1) mc:stm32mp15x-buster:linux-mainline:do_dpkg_build perform mounting of
WORKDIR to buildchroot-target/WORKDIR, then failed and leave WORKDIR to
be mounted.
2) mc:de0-nano-soc-buster:linux-mainline:do_dpkg_build perform the same
mount again which lead to circullar mount
WORKDIR->WORKDIR->buildchroot-target/WORKDIR, then package build is
performed without errors.
3) mc:de0-nano-soc-buster:linux-mainline:do_dpkg_build stuck inside
dpkg_undo_mounts. When package build finish it will put
run.dpkg_undo_mounts.PID shell function into WORKDIR/temp and execute.
But when run.dpkg_undo_mounts.PID try to unmount
buildchroot-target/WORKDIR the kernel will also unmount circullar mount
to WORKDIR which is locked by run.dpkg_undo_mounts.PID itself.
This scenario can be demonstrated with the following steps:
$ mkdir dirA
$ mkdir dirB
$ echo "sudo umount /home/user/dirB" > dirA/um
$ sudo mount --bind dirA dirB
$ mount | grep dir
/dev/sdb1 on /home/user/dirB type ext4 (rw,relatime)
$ sudo mount --bind dirA dirB
$ mount | grep dir
/dev/sdb1 on /home/user/dirB type ext4 (rw,relatime)
/dev/sdb1 on /home/user/dirB type ext4 (rw,relatime)
/dev/sdb1 on /home/user/dirA type ext4 (rw,relatime)
$ bash ~/dirA/um
umount: /home/user/dirB: target is busy.
So mount rebuild patchset actually make dpkg_undo_mounts to be always
run even after build fail and not allow double mounting.
It was done only for dpkg_do_mounts/dpkg_undo_mounts because only for
this scenario double mount is critical and can lead to dead lock.
Implementation can be completed for all the mounts if needed.
We understand that the API change is quite significant. I'm checking
whether the final unmounting could be solved without change the API.
P.S. in case anyone will try to reproduce the original issue this patch
can help:
diff --git a/meta-isar/recipes-kernel/linux/linux-mainline_5.4.70.bb
b/meta-isar/recipes-kernel/linux/linux-mainline_5.4.70.bb
index 209ad9c..49b9739 100644
--- a/meta-isar/recipes-kernel/linux/linux-mainline_5.4.70.bb
+++ b/meta-isar/recipes-kernel/linux/linux-mainline_5.4.70.bb
@@ -32,3 +32,11 @@ dpkg_configure_kernel_append() {
grep "CONFIG_ROOT_NFS=y" ${S}/${KERNEL_BUILD_DIR}/.config || \
bbfatal "Self-check failed: CONFIG_ROOT_NFS not enabled"
}
+
+dpkg_runbuild_prepend() {
+ if [ ! -e "${WORKDIR}/stampfile" ]; then
+ touch "${WORKDIR}/stampfile"
+ sleep 5
+ exit 1
+ fi
+}
--
Anton Mikanovich
Promwad Ltd.
External service provider of ilbers GmbH
Maria-Merian-Str. 8
85521 Ottobrunn, Germany
+49 (89) 122 67 24-0
Commercial register Munich, HRB 214197
General Manager: Baurzhan Ismagulov
next prev parent reply other threads:[~2021-07-05 14:30 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-23 11:58 Anton Mikanovich
2021-06-25 8:19 ` Moessbauer, Felix
2021-06-25 11:25 ` Anton Mikanovich
2021-06-29 13:49 ` Jan Kiszka
2021-07-05 14:30 ` Anton Mikanovich [this message]
2021-07-26 14:34 ` Anton Mikanovich
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=6574c75e-c25b-8060-3f26-681ef842b995@ilbers.de \
--to=amikan@ilbers.de \
--cc=felix.moessbauer@siemens.com \
--cc=henning.schild@siemens.com \
--cc=ibr@ilbers.de \
--cc=isar-users@googlegroups.com \
--cc=jan.kiszka@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