From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6487873763254730752 X-Received: by 10.46.21.86 with SMTP id 22mr934825ljv.28.1510645069048; Mon, 13 Nov 2017 23:37:49 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 10.46.25.80 with SMTP id p77ls4410780lje.1.gmail; Mon, 13 Nov 2017 23:37:48 -0800 (PST) X-Google-Smtp-Source: AGs4zMYZRkkrtvWM9Rq8uY6h2OBYy2xvix4prZFm9JNwiTK3mzeaVA+/3lIdA8SAYeFR7YmACogu X-Received: by 10.25.80.67 with SMTP id z3mr708387lfj.6.1510645068625; Mon, 13 Nov 2017 23:37:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1510645068; cv=none; d=google.com; s=arc-20160816; b=Scv80f+t5o08G0/5ZSfSWaw/Z6Nf9Qab3G9wnEudDzbzZyw4XFmWr8iERuLg/3KbUV 2UcsROScLGR3PtFqAE8phXzrYQM1HSaZrO1YbLpq4sApdUUIGRG8a34QQ8j2YOO/Nce7 9O3e3ZUE/q64APr/YPiyBKz8oUeO6pEDHeBhmspVBzUDFFt4mdnyyCPO42V6ymYiHafA HDC6diH8XG7eYSneGgLz9w7bTzuUlZNk55n6E3JMcdK+agCmahiyReqzl9O9DMYG19WN L7VxJZlrABvn2QYUkMHPTsigLSqm4L5W16CCvrtsg/Jy+UKQG/jqFaOn5wcMbzBvuAjP gZpA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:mail-followup-to:message-id :subject:to:from:date:arc-authentication-results; bh=D4Er1l1lNG6Zmgifnyoa1uCVX0AZZvnaMPJbpleKX5c=; b=L7tWsGK8mYP1b2jGupd9AXay1SWV2ErJCht/vG/V8TYcDo3JTmhscPG9lsZfjXYUlN ZAFLzRVWT4EKbl/B/z5JcKDqr2sdBMqQo/EjZoB7I/8NyBDJsWCgZflod7a3uUIVu5xH 1cRA2BC+5ydl6kEh5taXniuA8IMG01vET3t9jCK4cTp2Y1+TR//5Z1p9xN+tCqQRnI9m ehlOExPgu74BkaDtpHjKAXZEZ1meu6ItIfLrSM4ZK4Km5pcPyKIlSEyCTbfsBGe31r6y 1yIKpQlmQe01eQN1ZxbR1vU45bR+9rVwb7AEW3GJ1bZ+jpG+4UzkFpB/IdKtvxD+PK4M XJIg== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of christian.storm@siemens.com designates 192.35.17.2 as permitted sender) smtp.mailfrom=christian.storm@siemens.com Return-Path: Received: from thoth.sbs.de (thoth.sbs.de. [192.35.17.2]) by gmr-mx.google.com with ESMTPS id b78si53897ljf.3.2017.11.13.23.37.48 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 23:37:48 -0800 (PST) Received-SPF: pass (google.com: domain of christian.storm@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 christian.storm@siemens.com designates 192.35.17.2 as permitted sender) smtp.mailfrom=christian.storm@siemens.com Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by thoth.sbs.de (8.15.2/8.15.2) with ESMTPS id vAE7blMK029507 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 14 Nov 2017 08:37:47 +0100 Received: from localhost ([139.25.69.251]) by mail3.siemens.de (8.15.2/8.15.2) with ESMTPS id vAE7blon024464 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 14 Nov 2017 08:37:47 +0100 Date: Tue, 14 Nov 2017 08:36:38 +0100 From: Christian Storm To: isar-users@googlegroups.com Subject: Re: [PATCH] isar-image-base: fix some dangling mounts Message-ID: <20171114073638.zlmujtvd2lt337nn@MD1KR9XC.ww002.siemens.net> Mail-Followup-To: isar-users@googlegroups.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <176ee2a2-7f5b-8395-80c8-ca4df6ecf952@ilbers.de> User-Agent: Mutt/20170113 (1.7.2) X-TUID: wkf2sJKlm6ci > >> [...] > >> Here I see that you insert quite similar patterns across the Isar code, > >> would it be better to have one global clean up function like? > >> > >> do_isar_mount_cleanup () { > >> if [ -d "${WORKDIR}/mnt" ]; then > >> # umount and remove > >> fi > >> > >> if [ -d "${WORKDIR}/rootfs/proc" ]; then > >> # umount and remove > >> fi > >> > >> if [ -d "${BUILDCHROOT_DIR}/proc" ]; then > >> # umount and remove > >> fi > >> > >> etc... > >> } > >> > >> This approach will significantly simplify maintenance of clean up traps > >> and adding of new possible mounts to Isar. What do you think? > > > > I'd say it depends :) > > It breaks if you rely on keeping something mounted while executing a > > child script that does unmount everything, following your proposal. If > > we can make sure that such a situation never occurs, we may consolidate > > this. For now, it's rather local just undoing the mounts done in the > > scope of the script. > > So, in the end, I think it's a matter of taste and contracts between the > > different parts of Isar. > > > > Ok. > > > What one may consider to "de-duplicate" is a stack of mounted directories > > being pushed to and unmounted on script exit. So, something like > > push_umount ${IMAGE_ROOTFS}/proc > > and then the EXIT trap enumerates all those entries, unmounting them. > > The same has to be done for removing the directories, if applicable. > > This sounds reasonable, will try to implement this? > > BTW: for me it's not the point for me to block current patch, it'd be > very helpful to have it in the tree now. OK, then let's merge it and create a github issue to refactor it later as I do have more mount-related stuff in my queue :) Once all mount-related patches are merged, we do have a clearer picture and can account for all this at once in terms of a discussion and a proper concept on the github issue. So, I propose we merge this and I'll send the other patches out once ready and then we do a refactoring with discussion on the right way to do it on the github issue. My proposal with the stack may serve as a starting point for discussion on the github issue. What do you think? Would that be OK for you? Besten Gru�, Christian -- Dr. Christian Storm Siemens AG, Corporate Technology, CT RDA ITP SES-DE Otto-Hahn-Ring 6, 81739 M�nchen, Germany