From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6982576501791129600 X-Received: by 2002:a05:600c:3595:: with SMTP id p21mr17132431wmq.105.1627315309017; Mon, 26 Jul 2021 09:01:49 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a05:600c:511e:: with SMTP id o30ls10456971wms.2.canary-gmail; Mon, 26 Jul 2021 09:01:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxP/lxBGUjL1kkTCJn0oHpP8LKSe04Ip/gow4hXkVBaNncVOYwNc7BfW+EhKadloS2qS/LN X-Received: by 2002:a1c:7208:: with SMTP id n8mr8697150wmc.89.1627315307840; Mon, 26 Jul 2021 09:01:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1627315307; cv=none; d=google.com; s=arc-20160816; b=QaxsDT4W9yHNBa/NO3UZLdd5vyuKB8Bt4vX3f69Kvx0Wtd+pe8X8e68I+7SXdzlc2Z 8eBfdonfsbPaLmAdidwq/cwRm3VuJDlXzdfVxG2a+0P+ySE4b/F1BdB1MsPzXwdLprmi 7vzsgyTe1dI8aSpR9aHiR0xzVj4Vlh03FNrD2m6EG0zd+B8l1P7O31SWJAI5k6wos7N+ Hi7sUdPQbxxZV4GKL5Mdtt8cHQ+h0qQ7BTdNVDQ+CoNgErUcrpcTI1/fWhbLZAtnwd7o dlEP8CoSZBy1a+heH6q/510jv5WGKyqnRS+48w2ceSiAWZKvdX+169+51FGJP/AxCOgB wlbw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:to:subject; bh=3oe8hXyhwPNcX4WfcvWVBXUOfD9TfHmOUsYs+mD2dn0=; b=VJkj+rm6ltO/0iCkuizU4+NY39XdSk1p0cnMIZkiNfC9u1raRpK6GcgTzA5dIVVU9R YP9/W38Qi6yVF/IHXezsoHbiHKOQP/EgfxnDseOb6rQT/X85dVNF8qi01r5lNLRHWwnG vHqsNG1sBdypehOZAacP3FvSAmU+ypNLaS6PNN6Rl8zD9CQjZ7Mp6+/Uhw6koqbStr+I MFBASypAiaH6BLRjD9I3JmFwQYYny3EQ/bxJ7PC0i3VdKRxoSAx5KQypzy2erFM+2bYy lvlDhH6awpNazUGqDgAY6iu+hsr3TW/ACGPjRvvPDh7mp9sdxlmzWN6Gb0g/tuvDic30 Gl1A== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.2 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from thoth.sbs.de (thoth.sbs.de. [192.35.17.2]) by gmr-mx.google.com with ESMTPS id k19si7177wms.1.2021.07.26.09.01.47 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Jul 2021 09:01:47 -0700 (PDT) Received-SPF: pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.2 as permitted sender) client-ip=192.35.17.2; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.2 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by thoth.sbs.de (8.15.2/8.15.2) with ESMTPS id 16QG1lXB005165 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 26 Jul 2021 18:01:47 +0200 Received: from [167.87.33.191] ([167.87.33.191]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 16QG1kTL022866 for ; Mon, 26 Jul 2021 18:01:47 +0200 Subject: Re: [PATCH] rootfs: Use separate mounts lock file To: isar-users@googlegroups.com References: <20210708152251.220337-1-amikan@ilbers.de> <1b0c9da5-f080-3500-c697-53333528eaad@ilbers.de> <20210726154658.GM18446@yssyq.m.ilbers.de> From: Jan Kiszka Message-ID: Date: Mon, 26 Jul 2021 18:01:46 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <20210726154658.GM18446@yssyq.m.ilbers.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: lMgXwg+Dik1q On 26.07.21 17:46, Baurzhan Ismagulov wrote: > 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. > OK, then let's document that in the commit and merge it. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux