From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6631438923266523136 X-Received: by 2002:a2e:4253:: with SMTP id p80-v6mr2262850lja.13.1544013349163; Wed, 05 Dec 2018 04:35:49 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a19:7609:: with SMTP id c9ls1963792lff.0.gmail; Wed, 05 Dec 2018 04:35:48 -0800 (PST) X-Google-Smtp-Source: AFSGD/VsYKUnnE1w1uBq4tdUokamF057+XevpVx5ewKnvkkt0xm12ZAi63l3elkMTJJim7UjoVJJ X-Received: by 2002:ac2:42d0:: with SMTP id n16mr1946479lfl.5.1544013348542; Wed, 05 Dec 2018 04:35:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544013348; cv=none; d=google.com; s=arc-20160816; b=f1DorZY1U5JW9L3cncQX/Eo5sztVDLohDoElZsDvwqrh16NW48VSM2pGbMXg+l0l6Z Joflv6LmGdW84svwzxorsQqKYfiewI/AxZwbM0TKinpqP9VSKQ/d2zxud98fi/amBRIn PMK2kdz76NU5xW5KDATgKcTapsYH19QOfLcuhUc7IkaVH6xj8pILaoRspMnENodnHxXd EmMTutzlfUNi2rexBwKFeJ0nqRxvUdfev50nookizRwvsJuz/cQLuD1Hbq4GmhhXCLt/ nXmCQhVJcL0KcrBgfrZbAZUScu3AWmk5ZPDTcp21pa7XlYsqB8i/gvdVJNXis6JhOmJm /luQ== 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=MhlE27ZNmS3P4bfZ/zF2D8AYCJ9wT9uixf9PU2f9ibY=; b=tpMgUkoN3lZHpEikUW9DHD8qalh0zLtEC61OjEq/1DEo6MYRKxwYruteRHhylMWGBn xjfA/NvFwPI/gj5nssWU8kB/yRaMRdWqjBkCc/UzLS21pu5Fds2857WRbPDCkz1lkPUW K5gCqNfq8gOJSwairslu7f3uEqT9fVnVmsf8LQvNIwTJ10ZjaAQnZeOGO+2WInp5xWwq jdK4L6N1D0mi4yg7tPzZ6j2LFNmdSnXZOCCifiKtwCmu6+gMjWEBAXCePYjwt+cGfPnl QSm00WP+N/6NNykXT7XSl9ez8wDr4l3qZ9JUPPWzvIjWfaDaK/b5WBbswwTo73le6IjM VlcA== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com Return-Path: Received: from goliath.siemens.de (goliath.siemens.de. [192.35.17.28]) by gmr-mx.google.com with ESMTPS id 81-v6si556850ljc.2.2018.12.05.04.35.48 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Dec 2018 04:35:48 -0800 (PST) Received-SPF: pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.28 as permitted sender) client-ip=192.35.17.28; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id wB5CZl7F029303 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 5 Dec 2018 13:35:47 +0100 Received: from [139.25.68.37] (md1q0hnc.ad001.siemens.net [139.25.68.37] (may be forged)) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id wB5CZl3o026888; Wed, 5 Dec 2018 13:35:47 +0100 Subject: Re: [PATCH 0/3] umount fixes and cleanups To: "Hombourger, Cedric" , "Maxim Yu. Osipov" , isar-users References: <02edaac4-fc2d-44ea-6471-52ad8fc3d421@siemens.com> <32728b629b094f79ad589524d097ffb2@svr-ies-mbx-02.mgc.mentorg.com> From: Jan Kiszka Message-ID: Date: Wed, 5 Dec 2018 13:35:46 +0100 User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 In-Reply-To: <32728b629b094f79ad589524d097ffb2@svr-ies-mbx-02.mgc.mentorg.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-TUID: tfy6H/5Uv14d On 05.12.18 13:31, Hombourger, Cedric wrote: > I was able to use the following work-around for your test-case: > > # run the following command until all mounts are gone > umount $(mount |grep $PWD/my-mnt|awk '{print $3}') Does that listing always produce the right ordering for umount, or does the order not matter? Just for me to remember: We do want the recursive mounts, don't we? Or, said differently, what is the downside of Maxim's revert for use cases you see? Jan > > umount -R or -l indeed failed > > Cedric > > -----Original Message----- > From: Jan Kiszka [mailto:jan.kiszka@siemens.com] > Sent: Wednesday, December 5, 2018 3:15 PM > To: Maxim Yu. Osipov ; isar-users > Cc: Hombourger, Cedric > Subject: Re: [PATCH 0/3] umount fixes and cleanups > > On 05.12.18 12:12, Maxim Yu. Osipov wrote: >> On 12/5/18 12:29 PM, Jan Kiszka wrote: >>> Patches related to resolving the pending CI issues as well as >>> simplifying the umounts used during cleanup. >> >> Tried to run in patch queue: >> >> 027b7cf Remove redundant recursive umounts >> c1bdc33 isar-events: Improve umount handler >> b354273 ci: Wait for bitbake worker to finish before deleting >> artifacts >> 9cf29e6 isar-bootstrap: Fix and cleanup bind mounting >> b354026 isar-image: umount base-apt when doing offline build e965c0d >> gitlab-ci: Switch to ci_build.sh ... >> >> After execution of problematic test case (I rebooted PC and executed >> steps in clean tree): >> >> my stretch Debian system was entered into unusable state as many >> important mounts were disappeared (see log of mount points before and >> after execution  of last command attached). > > OK, so I took the time and extracted the root cause. We may see a Debian 4.9 kernel bug here: > > # mkdir my-mnt > # mount --rbind /sys my-mnt > # mount --make-rslave my-mnt > # umount {-R,-l,-R -l} my-mnt > # rmdir my-mnt > rmdir: failed to remove 'my-mnt': Device or resource busy > > This works fine on my Leap 15.0 kernel (4.12) as well as the 4.4 kernel (Ubuntu) used on our CI server. > > *This* is information we can base commits on. Also, we can file a bug against Debian with this. Could you do that (keep my in CC)? > > Thanks, > Jan > > -- > Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux > -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux