Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1574374pxb; Mon, 8 Mar 2021 00:31:59 -0800 (PST) X-Google-Smtp-Source: ABdhPJwz1edhgGs3ycH+r6pbp2lLt8nKbZnDilpDTlNpgWfHFWp9SK+wDrcU+l+aKpIjQ6jOXoO2 X-Received: by 2002:a17:906:7c57:: with SMTP id g23mr13493781ejp.195.1615192319325; Mon, 08 Mar 2021 00:31:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1615192319; cv=none; d=google.com; s=arc-20160816; b=HBeJNp2jnsm313K5hPv+5Zgc3VoXy0etrGgkm4cBjiowcrybOucQ27aOKGHCbRU+0g HiSWJAxzfLYcsGR0mUr/etpH9I+Oqb/93wCVxYIxJUeoroWJV55JCYdO5FNiTb2J/scI HygaVzpCkIwwP2ievnZb3zGn/5JX7e9Kb6i6xs5aN9juYqUs8vXroSL49nr4JarBasQ5 q99ynqo0BalGAWPqC4qgePsxYbtNBRBXGfZUQ8lP5VdVB6hyqan5o48zB2t7bh6ptAOV QvRrGJC7aMpl4jPvfN5RCaJGfLU9o2Bm6oXrPNS9xOBk/ULA6uuti3vTBl6sArHyVNF1 2tcw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=QRO/XOu4NxUWDsDQvrvygz/hZqRVN+PuN5wj0h8Huaw=; b=EVYx2jQT5bR2IgcykMxQup1gVS7ID/HjuW4OdqZSI+GkqFOiqNSphdbt//H1OQ9AbO R/4oh5tnSjn9V22+vSTaxBVOWez44tM6wL5VhaL8mHKNmPaUNz7TzoKxl23ANl7tkEsL 7I6tbXP/NGTocWLEQ5cHWMx5PIg6cKIgGMVGty4rSROD5klGi/WdWIEpYUiJp4B1hVQl pqIR+NwKywF9WolloM5m0buNt6GJfWdXJbWyIbnlm9hMst3fzAx2W8EtpGDmSglCy3dW Z2OMQofVa8BfiWduybWEPB6BMigCSXMicAERTAYQhvk05YwVWlou3256LoBdJtwJCj2i CBpg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v7si7094427edj.308.2021.03.08.00.31.37; Mon, 08 Mar 2021 00:31:59 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233300AbhCGXyC (ORCPT + 99 others); Sun, 7 Mar 2021 18:54:02 -0500 Received: from zeniv-ca.linux.org.uk ([142.44.231.140]:34702 "EHLO zeniv-ca.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231894AbhCGXxz (ORCPT ); Sun, 7 Mar 2021 18:53:55 -0500 Received: from viro by zeniv-ca.linux.org.uk with local (Exim 4.94 #2 (Red Hat Linux)) id 1lJ3BA-003qHP-4O; Sun, 07 Mar 2021 23:51:20 +0000 Date: Sun, 7 Mar 2021 23:51:20 +0000 From: Al Viro To: Alexander Mikhalitsyn Cc: Ian Kent , Matthew Wilcox , Pavel Tikhomirov , Kirill Tkhai , autofs@vger.kernel.org, linux-kernel@vger.kernel.org, Miklos Szeredi , Christian Brauner , Ross Zwisler , Aleksa Sarai , Eric Biggers , Mattias Nissler , linux-fsdevel@vger.kernel.org, alexander@mihalicyn.com Subject: Re: [RFC PATCH] autofs: find_autofs_mount overmounted parent support Message-ID: References: <20210303152931.771996-1-alexander.mikhalitsyn@virtuozzo.com> <832c1a384dc0b71b2902accf3091ea84381acc10.camel@themaw.net> <20210304131133.0ad93dee12a17f41f4052bcb@virtuozzo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210304131133.0ad93dee12a17f41f4052bcb@virtuozzo.com> Sender: Al Viro Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 04, 2021 at 01:11:33PM +0300, Alexander Mikhalitsyn wrote: > That problem connected with CRIU (Checkpoint-Restore in Userspace) project. > In CRIU we have support of autofs mounts C/R. To acheive that we need to use > ioctl's from /dev/autofs to get data about mounts, restore mount as catatonic > (if needed), change pipe fd and so on. But the problem is that during CRIU > dump we may meet situation when VFS subtree where autofs mount present was > overmounted as whole. > > Simpliest example is /proc/sys/fs/binfmt_misc. This mount present on most > GNU/Linux distributions by default. For instance on my Fedora 33: > > trigger automount of binfmt_misc > $ ls /proc/sys/fs/binfmt_misc > > $ cat /proc/1/mountinfo | grep binfmt > 35 24 0:36 / /proc/sys/fs/binfmt_misc rw,relatime shared:16 - autofs systemd-1 rw,...,direct,pipe_ino=223 > 632 35 0:56 / /proc/sys/fs/binfmt_misc rw,...,relatime shared:315 - binfmt_misc binfmt_misc rw > > $ sudo unshare -m -p --fork --mount-proc sh > # cat /proc/self/mountinfo | grep "/proc" > 828 809 0:23 / /proc rw,nosuid,nodev,noexec,relatime - proc proc rw > 829 828 0:36 / /proc/sys/fs/binfmt_misc rw,relatime - autofs systemd-1 rw,...,direct,pipe_ino=223 > 943 829 0:56 / /proc/sys/fs/binfmt_misc rw,...,relatime - binfmt_misc binfmt_misc rw > 949 828 0:57 / /proc rw...,relatime - proc proc rw > > As we can see now autofs mount /proc/sys/fs/binfmt_misc is inaccessible. > If we do something like: > > struct autofs_dev_ioctl *param; > param = malloc(...); > devfd = open("/dev/autofs", O_RDONLY); > init_autofs_dev_ioctl(param); > param->size = size; > strcpy(param->path, "/proc/sys/fs/binfmt_misc"); > param->openmount.devid = 36; > err = ioctl(devfd, AUTOFS_DEV_IOCTL_OPENMOUNT, param) > > now we get err = -ENOENT. Where does that -ENOENT come from? AFAICS, pathwalk ought to succeed and return you the root of overmounting binfmt_misc. Why doesn't the loop in find_autofs_mount() locate anything it would accept? I really dislike the patch - the whole "normalize path" thing is fundamentally bogus, not to mention the iterator over all mounts, etc., so I would like to understand what the hell is going on before even thinking of *not* NAKing it on sight.