Re: [PATCH 0/3] umount fixes and cleanups

[Jan Kiszka <jan.kiszka@siemens.com>]

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 <mosipov@ilbers.de>; isar-users <isar-users@googlegroups.com>
> Cc: Hombourger, Cedric <Cedric_Hombourger@mentor.com>
> 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