From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6982576501791129600 X-Received: by 2002:adf:f592:: with SMTP id f18mr19569554wro.179.1627314427368; Mon, 26 Jul 2021 08:47:07 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a5d:4c50:: with SMTP id n16ls2004668wrt.2.gmail; Mon, 26 Jul 2021 08:47:06 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwbusOAlMbcx73QtivsH1kUV6p9MoWhip2aqSpLxbh+QkSEmrDsD0ODdhsw/yfNWvF9IrYy X-Received: by 2002:a05:6000:1886:: with SMTP id a6mr20090939wri.17.1627314426379; Mon, 26 Jul 2021 08:47:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1627314426; cv=none; d=google.com; s=arc-20160816; b=fliCZNiaNHlOZcwXPyw5JZovhLMurxmkiq1yxTzlhZNmEB7yZXGxgct86KH2u5v+ph Wcr+ilRGfLAiAwpKiEIPPtlpxl6wos8tU0DJ9Q70CDLJWmcKHpx/d2kIZBHQG6y0/4qW TQNnmJuiyf1/b41hPmxGfz/6GHGbDsa7s0dj9bq6vcK6urIVLkBxLq95reaD8RwqNQkg Kx+Rlqva45/RKOitp6fndwWePX+50FHTWxXZZn2fq239B6K+Prm9M/DXK3DzCKL2SkgC O1oh+KlyOdl5VWHf/LAoOqtuJkcYh9JODTJiOExPa22kR3leybioQaVg4ZgLlbIpcTgf E0mw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:to:from:date; bh=JXzH0hYLuUiEEG6A2xGUU2XY579Tu7bqQ94ihnXFOiU=; b=qo99XqLfQnRi4lZ4YcV7Cm6nFHstrV7ev2hI/01DgHxkgo7GqtfgnJWEykPlN7Nfb/ SyDHt9JHAhD/B3k+MlhhwFjYYwYvRXcGr4V7RNLRlcb/HbOKHNv8upMY2bAI/mFzdUTe 4qL5sk3HtBfBoD9HQrlL5r5kKZj2CnuT500K7vBbntv5zoy6m1d6qNIy4nwtSAYUTp3T 1HR7mm38Msd9TZyw/VXvWqHDrfXZgDRYXtB+AsJUfv8NsoffB+0CM/1NymvECS0kSHv+ cFqp/6wQJyolcmZHt8yf62jEyS5cK0jhAhtpIbswcY4GdSgnPCrn4SEpI7UrPaD5W3H/ W1JA== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=neutral (google.com: 85.214.156.166 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) smtp.mailfrom=ibr@radix50.net Return-Path: Received: from shymkent.ilbers.de (shymkent.ilbers.de. [85.214.156.166]) by gmr-mx.google.com with ESMTPS id u16si14044wrg.5.2021.07.26.08.47.06 for (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Mon, 26 Jul 2021 08:47:06 -0700 (PDT) Received-SPF: neutral (google.com: 85.214.156.166 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) client-ip=85.214.156.166; Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 85.214.156.166 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) smtp.mailfrom=ibr@radix50.net Received: from yssyq.m.ilbers.de (ip-109-43-51-147.web.vodafone.de [109.43.51.147]) (authenticated bits=0) by shymkent.ilbers.de (8.15.2/8.15.2/Debian-8) with ESMTPSA id 16QFl4Sv020773 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 26 Jul 2021 17:47:05 +0200 Date: Mon, 26 Jul 2021 17:46:59 +0200 From: Baurzhan Ismagulov To: isar-users@googlegroups.com Subject: Re: [PATCH] rootfs: Use separate mounts lock file Message-ID: <20210726154658.GM18446@yssyq.m.ilbers.de> Mail-Followup-To: isar-users@googlegroups.com References: <20210708152251.220337-1-amikan@ilbers.de> <1b0c9da5-f080-3500-c697-53333528eaad@ilbers.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1b0c9da5-f080-3500-c697-53333528eaad@ilbers.de> User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on shymkent.ilbers.de X-TUID: +7aNwRBQp86i On Mon, Jul 26, 2021 at 05:44:26PM +0300, Anton Mikanovich wrote: > > Definitely a good catch, but I'm still wrapping my head around it. We > > either have really separated rootfs'es here so that separated lock files > > are fine, or we rather want rootfs_do_mounts to be locked against > > buildchroot_do_mounts as well. At least conceptually, even if they well > > never run in parallel in practice. In that case, MOUNT_LOCKFILE in > > rootfs.bbclass should be made a weak assignment, to clarify that > > buildchroot.bbclass will win, irrespective of any ordering. > > > We've performed additional checking and testing of parallel > mounting/unmounting and didn't find any issues there. > So I'm pretty sure this should be merged. To explain the background, we couldn't identify any resource sharing in any combination of buildchroot and rootfses, so a separate lock has been recently introduced in e438c8f6 "rootfs: Unmount rootfs mounts if not needed". This didn't work correctly, as described in the commit message. Regarding *_do_mounts, they would need to be serialized if mount(8) would have unlocked shared resources. At least a simple script running 100 mounts and umounts in parallel didn't reveal any issues. With kind regards, Baurzhan.