From owner-freebsd-arch@freebsd.org Fri Sep 15 16:06:11 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E53A3E1F972; Fri, 15 Sep 2017 16:06:11 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 97E2D6D958; Fri, 15 Sep 2017 16:06:11 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by mail-vk0-x232.google.com with SMTP id z187so1243413vkd.13; Fri, 15 Sep 2017 09:06:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=t+d19FruIl6nVb34JPaYdPppoSC01L1YhVjmk3RJQMY=; b=FF0lVHJRCb1Kw6zki8WJ5nGbHOZ/oKmnoLXdHSoEThD1bvEEq6P22ljBlNyHnk9jAY ZR0CF8NKdmwHNNB/hej6hcxyrIm+7J2gi9z//k4/RPp5l+SFx9jxDwx2vCwu68zJR27C JkzZ5ZqHhK23cvUKW3uNPXAeNsOvF2GbITOW9xE88kAQwUxleEN0bW38sCES4FMVJRty EM71jMtzNy83UM0HlpvbNOb2cznfP1P2YxtofXHepzAv+TD/lPp+5NAuvTVA1L8JiKu6 LmAKyClmXvWQoco5MKJVdDuGMIEkPYetitU4keeNS0b28rRyMI0Yt1mONcGozjA3Rh1h lzNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=t+d19FruIl6nVb34JPaYdPppoSC01L1YhVjmk3RJQMY=; b=d28UWVLA/XHBC8aj+zYDAsZ7Owq1t9vM7C7j4ON+muBwY3UZId4pOwuOmJgXy9XywR Dkqav7F1n6dgnyU03MTLwW3pDWw8cGi98j8fm9GIata1713BeV0w38dfTbBSJ1vA0qim pqGqCXnPZQRnwjGE9uOgPkpkgZxr7P77cPA9Ea2f9QmTF+vz4F0fd4VgATimcJ2ZaAXE IrK3MvIoSGFhTLY2tE0Uoo5M8YNDHoBCTIIBa1Ogp0e0yh5svT4TBhApwYZkh2u4EsI3 7vE5U2j2TrhVHVdc64adl43avwZYLeQOEz9AD/oRvBbLVAX8yWC9q5onruXBos29v4UY SoyA== X-Gm-Message-State: AHPjjUgBnA8eUdjhhwWVIpQFavXOhBZjMDUpCB1/sUY8yCy7bQHA3qiq xafQtX1C9NZB1P5mAKgeBiS0mkgKLIL5VxOO38I= X-Google-Smtp-Source: AOwi7QDwvvBDFnW6Qpoq4ZO6sbhzScbi/yn3lwPPjOk3fQcug7RaUchHdqsoXLEghhIwY5R97ksiEtIb3Ubh+9nRXu8= X-Received: by 10.31.10.19 with SMTP id 19mr19326393vkk.3.1505491570639; Fri, 15 Sep 2017 09:06:10 -0700 (PDT) MIME-Version: 1.0 Sender: etnapierala@gmail.com Received: by 10.159.51.232 with HTTP; Fri, 15 Sep 2017 09:06:10 -0700 (PDT) In-Reply-To: <20170915114533.GS78693@kib.kiev.ua> References: <134c7c6e-f4f1-ef38-cc50-0e56c27c9fb8@FreeBSD.org> <201709150314.v8F3Ea6B085072@chez.mckusick.com> <20170915092001.GK78693@kib.kiev.ua> <20170915103037.GM78693@kib.kiev.ua> <20170915110033.GO78693@kib.kiev.ua> <20170915114533.GS78693@kib.kiev.ua> From: Edward Napierala Date: Fri, 15 Sep 2017 17:06:10 +0100 X-Google-Sender-Auth: qCK8B-Up8hPQ1H4SxiHOdnDAhy0 Message-ID: Subject: Re: mount / unmount and mountcheckdirs() To: Konstantin Belousov Cc: Kirk McKusick , freebsd-fs , Andriy Gapon , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 16:06:12 -0000 2017-09-15 12:45 GMT+01:00 Konstantin Belousov : > On Fri, Sep 15, 2017 at 12:31:05PM +0100, Edward Napierala wrote: > > 2017-09-15 12:00 GMT+01:00 Konstantin Belousov : > > > > > On Fri, Sep 15, 2017 at 11:49:17AM +0100, Edward Napierala wrote: > > > > 2017-09-15 11:30 GMT+01:00 Konstantin Belousov >: > > > > > > > > > On Fri, Sep 15, 2017 at 11:08:31AM +0100, Edward Napierala wrote: > > > > > > 2017-09-15 10:20 GMT+01:00 Konstantin Belousov < > kostikbel@gmail.com > > > >: > > > > > > > I believe that the current autofs does not allow a process to > get > > > into > > > > > > > this situation at all. > > > > > > > > > > > > > > > > > > > It does. For example: > > > > > > > > > > > > [trasz@v2:~]% cd /media/md0 > > > > > > [trasz@v2:/media/md0]% mount > > > > > > /dev/ada0s1a on / (ufs, local, noatime, journaled soft-updates) > > > > > > devfs on /dev (devfs, local, multilabel) > > > > > > map -hosts on /net (autofs) > > > > > > map -media on /media (autofs) > > > > > > [trasz@v2:/media/md0]% ls > > > > > > [trasz@v2:/media/md0]% mount > > > > > > /dev/ada0s1a on / (ufs, local, noatime, journaled soft-updates) > > > > > > devfs on /dev (devfs, local, multilabel) > > > > > > map -hosts on /net (autofs) > > > > > > map -media on /media (autofs) > > > > > > /dev/md0 on /media/md0 (ufs, local, noatime, nosuid, automounted) > > > > > > > > > > > > Getting rid of mountcheckdirs() in the unmount path should be > fine, I > > > > > think. > > > > > How the example proves that mountcheckdirs() can be removed ? > > > > > > > > > > > > In the unmount path? It doesn't; I just don't think autofs would be > > > > affected, > > > > since having a current working directory in a mountpoint prevents the > > > > unmount > > > > (unless it's forced). > > > > > > > > In the mount path? See below. > > > > > > > > > > > > > How can > > > > > we see which directory content was printed by ls, the covered or > > > mounted ? > > > > > > > > > > > > > Well, it would be pretty useless if you got the covered directory. > > > This is exactly what is being discussed. > > > > > > > But ok, here's > > > > a better example, one that actually shows that: > > > > > > > > [trasz@v2:/media/md0]% mount > > > > /dev/ada0s1a on / (ufs, local, noatime, journaled soft-updates) > > > > devfs on /dev (devfs, local, multilabel) > > > > map -hosts on /net (autofs) > > > > map -media on /media (autofs) > > > > [trasz@v2:/media/md0]% ls -al > > > > total 9 > > > > drwxr-xr-x 3 root wheel 512 Sep 10 10:16 . > > > > drwxr-xr-x 3 root wheel 512 Sep 8 11:42 .. > > > > drwxrwxr-x 2 root operator 512 Sep 10 10:16 .snap > > > > [trasz@v2:/media/md0]% mount > > > > /dev/ada0s1a on / (ufs, local, noatime, journaled soft-updates) > > > > devfs on /dev (devfs, local, multilabel) > > > > map -hosts on /net (autofs) > > > > map -media on /media (autofs) > > > > /dev/md0 on /media/md0 (ufs, local, noatime, nosuid, automounted) > > > > > > > > Notice the .snap/ directory; it's an empty UFS filesystem. > > > And the .snap is from the /dev/md0 volume, right ? > > > > > > > Yes. > > > > > > > If yes, then this demonstration indeed proves that autofs behaves as > > > intended on mount. > > > > > > > Exactly. And, from what I understand, that would break if > mountcheckdirs() > > got removed from the mount path. > > Even for autofs ? Don't autofs postpone lookup() completion until the > mount occurs ? > It does, and that case might work - I'm not sure, but it might. But what happens afterwards, after the syscall that triggered the mount completes? You would still have a shell with cwd in that dir, now covered by another filesystem. Autofs doesn't do anything to "lift" the process to the newly mounted filesystem root.