From: Claudius Heine <claudius.heine.ext@siemens.com>
To: "[ext] Jan Kiszka" <jan.kiszka@siemens.com>,
isar-users <isar-users@googlegroups.com>
Cc: Cedric Hombourger <Cedric_Hombourger@mentor.com>
Subject: Re: [PATCH 05/26] dpkg: Fix shared-locking of build task
Date: Mon, 26 Aug 2019 10:30:55 +0200 [thread overview]
Message-ID: <68263e5e-36ba-16d0-be9b-e8dfc8697ccf@siemens.com> (raw)
In-Reply-To: <0342bed12dfefb93ee9c2cc93282641a97a12042.1566800787.git.jan.kiszka@siemens.com>
Hi Jan,
On 26/08/2019 08.26, [ext] Jan Kiszka wrote:
> From: Jan Kiszka <jan.kiszka@siemens.com>
>
> Bitbake file locks are not just exclusive flock calls. For whatever
> reason, bitbake prefers to delete the lock file before unlocking them.
> That obviously creates a nasty race with other locker requests: Those
> already waiting will get access to the removed lock, those coming later
> will create a new one. To resolve that race, bitbakes lockfile() tests
> if the inode of the acquired lock file is identical to the one that is
> currently visible via the lock name. If not, it retries the lock. What a
> pointless mess...
>
> Our open-coded "flock -s" does not do that, thus will often acquire only
> a stale lock. Fix that by using bitbake's services for locking. That
> requires to move the lock acquisition at the top level of the task, ie.
> do_build. Thus, also dpkg-raw and kernel builds are now under the shared
> (read) lock. The better fix for this issue would actually be private
> buildchroots for each build, but that will come later.
>
> CC: Cedric Hombourger <Cedric_Hombourger@mentor.com>
> Fixes: 568072765b08 ("dpkg: acquire a read (shared) locks while building packages")
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> ---
> meta/classes/dpkg-base.bbclass | 11 +++++++----
> meta/classes/dpkg.bbclass | 5 ++---
> 2 files changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/meta/classes/dpkg-base.bbclass b/meta/classes/dpkg-base.bbclass
> index 2d26418..8146328 100644
> --- a/meta/classes/dpkg-base.bbclass
> +++ b/meta/classes/dpkg-base.bbclass
> @@ -87,10 +87,13 @@ dpkg_runbuild() {
> die "This should never be called, overwrite it in your derived class"
> }
>
> -do_build() {
> - dpkg_do_mounts
> - dpkg_runbuild
> - dpkg_undo_mounts
> +python do_build() {
> + lock = bb.utils.lockfile(d.getVar("REPO_ISAR_DIR") + "/isar.lock",
> + shared=True)
> + bb.build.exec_func("dpkg_do_mounts", d)
> + bb.build.exec_func("dpkg_runbuild", d)
> + bb.build.exec_func("dpkg_undo_mounts", d)
> + bb.utils.unlockfile(lock)
What is the difference between this and
do_build[lockfiles] += "${REPO_ISAR_DIR}/isar.lock"
?
regards,
Claudius
> }
>
> CLEANFUNCS += "repo_clean"
> diff --git a/meta/classes/dpkg.bbclass b/meta/classes/dpkg.bbclass
> index dd123c3..df47ced 100644
> --- a/meta/classes/dpkg.bbclass
> +++ b/meta/classes/dpkg.bbclass
> @@ -18,7 +18,6 @@ do_install_builddeps[lockfiles] += "${REPO_ISAR_DIR}/isar.lock"
> # Build package from sources using build script
> dpkg_runbuild() {
> E="${@ bb.utils.export_proxies(d)}"
> - flock -s "${REPO_ISAR_DIR}/isar.lock" \
> - sudo -E chroot --userspec=$( id -u ):$( id -g ) ${BUILDCHROOT_DIR} \
> - /isar/build.sh ${PP}/${PPS} ${DISTRO_ARCH}
> + sudo -E chroot --userspec=$( id -u ):$( id -g ) ${BUILDCHROOT_DIR} \
> + /isar/build.sh ${PP}/${PPS} ${DISTRO_ARCH}
> }
>
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: ch@denx.de
next prev parent reply other threads:[~2019-08-26 8:30 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-26 6:26 [PATCH 00/26] Tons of fixes and cleanups Jan Kiszka
2019-08-26 6:26 ` [PATCH 01/26] isar-bootstrap: Consider DISTRO_BOOTSTRAP_KEYS for gnupg installation Jan Kiszka
2019-08-26 6:26 ` [PATCH 02/26] isar-bootstrap: Fix keyring generation Jan Kiszka
2019-09-27 12:03 ` Baurzhan Ismagulov
2019-08-26 6:26 ` [PATCH 03/26] isar-bootstrap: Install DISTRO_BOOTSTRAP_KEYS Jan Kiszka
2019-08-26 6:26 ` [PATCH 04/26] Rework STAMP layout and cleaning Jan Kiszka
2019-08-26 8:30 ` Claudius Heine
2019-08-26 8:38 ` Jan Kiszka
2019-08-26 6:26 ` [PATCH 05/26] dpkg: Fix shared-locking of build task Jan Kiszka
2019-08-26 6:38 ` Cedric Hombourger
2019-08-26 8:30 ` Claudius Heine [this message]
2019-08-26 8:38 ` Jan Kiszka
2019-08-26 6:26 ` [PATCH 06/26] dpkg-base: Free do_build task Jan Kiszka
2019-08-26 6:26 ` [PATCH 07/26] base: Clean up build task Jan Kiszka
2019-08-26 8:30 ` Henning Schild
2019-08-26 8:40 ` Jan Kiszka
2019-08-26 6:26 ` [PATCH 08/26] isar-events: Do not start cleanup early Jan Kiszka
2019-08-26 6:26 ` [PATCH 09/26] meta-isar: Move bananapi to buster, remove bogus example Jan Kiszka
2019-09-04 6:53 ` [PATCH v2 " Jan Kiszka
2019-08-26 6:26 ` [PATCH 10/26] bitbake.conf: Reorder PV definition Jan Kiszka
2019-08-26 6:26 ` [PATCH 11/26] example-module: Fix build with mipsel target Jan Kiszka
2019-08-26 6:26 ` [PATCH 12/26] buildchroot: Ignore ISAR_CROSS_COMPILE for i386 on stretch Jan Kiszka
2019-08-26 6:26 ` [PATCH 13/26] buildchroot: Fix downgrades when installing dependencies Jan Kiszka
2019-08-26 6:26 ` [PATCH 14/26] buildchroot: Properly deploy the build result Jan Kiszka
2019-08-26 6:26 ` [PATCH 15/26] sdk: Use clean-package-cache rather than open-coded cleanup Jan Kiszka
2019-08-26 6:26 ` [PATCH 16/26] sdk: Deploy earlier Jan Kiszka
2019-08-26 6:26 ` [PATCH 17/26] Remove unneeded PF tweakings Jan Kiszka
2019-08-26 6:26 ` [PATCH 18/26] image: Stop changing PF, tune WORKDIR and STAMP directly Jan Kiszka
2019-08-26 8:35 ` Henning Schild
2019-08-26 8:40 ` Jan Kiszka
2019-08-26 6:26 ` [PATCH 19/26] image: Make WORKDIR and STAMPs IMAGE_TYPE-specific Jan Kiszka
2019-08-26 6:26 ` [PATCH 20/26] Adjust STAMP variables to use PN, rather than PF Jan Kiszka
2019-08-26 6:26 ` [PATCH 21/26] Align WORKDIR structure with OE Jan Kiszka
2019-08-26 6:26 ` [PATCH 22/26] isar-bootstrap: Clean up and fix rebuild Jan Kiszka
2019-09-21 8:28 ` Jan Kiszka
2019-08-26 6:26 ` [PATCH 23/26] gitlab-ci: Keep logs as artifacts on failure Jan Kiszka
2019-08-26 6:26 ` [PATCH 24/26] Detect false sharing of recipes Jan Kiszka
2019-08-26 6:26 ` [PATCH 25/26] dpkg-base: Move do_deploy_deb before do_build Jan Kiszka
2019-08-28 7:32 ` Claudius Heine
2019-10-01 11:49 ` Baurzhan Ismagulov
2019-08-26 6:26 ` [PATCH 26/26] base-apt: Move do_cache_config " Jan Kiszka
2019-08-26 21:29 ` [PATCH 27/26] wic-img: Use private tmp dir Jan Kiszka
2019-08-27 15:00 ` [PATCH v2 " Jan Kiszka
2019-10-01 14:43 ` [PATCH 00/26] Tons of fixes and cleanups Baurzhan Ismagulov
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=68263e5e-36ba-16d0-be9b-e8dfc8697ccf@siemens.com \
--to=claudius.heine.ext@siemens.com \
--cc=Cedric_Hombourger@mentor.com \
--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