Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Thu, 2 Apr 2020 17:50:20 +0200
From:   Lennart Poettering <mzxreary@0pointer.de>
To:     Miklos Szeredi <miklos@szeredi.hu>
Cc:     Ian Kent <raven@themaw.net>, David Howells <dhowells@redhat.com>,
        Christian Brauner <christian.brauner@ubuntu.com>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Al Viro <viro@zeniv.linux.org.uk>, dray@redhat.com,
        Karel Zak <kzak@redhat.com>,
        Miklos Szeredi <mszeredi@redhat.com>,
        Steven Whitehouse <swhiteho@redhat.com>,
        Jeff Layton <jlayton@redhat.com>, andres@anarazel.de,
        keyrings@vger.kernel.org, linux-fsdevel@vger.kernel.org,
        linux-kernel@vger.kernel.org, Aleksa Sarai <cyphar@cyphar.com>
Subject: Re: Upcoming: Notifications, FS notifications and fsinfo()
Message-ID: <20200402155020.GA31715@gardel-login>
References: <20200401144109.GA29945@gardel-login>
 <CAJfpegs3uDzFTE4PCjZ7aZsEh8b=iy_LqO1DBJoQzkP+i4aBmw@mail.gmail.com>
 <2590640.1585757211@warthog.procyon.org.uk>
 <CAJfpegsXqxizOGwa045jfT6YdUpMxpXET-yJ4T8qudyQbCGkHQ@mail.gmail.com>
 <36e45eae8ad78f7b8889d9d03b8846e78d735d28.camel@themaw.net>
 <CAJfpegsCDWehsTRQ9UJYuQnghnE=M8L0_bJBTTPA+Upu87t90w@mail.gmail.com>
 <20200402143623.GB31529@gardel-login>
 <CAJfpegtRi9epdxAeoVbm+7UxkZfzC6XmD4K_5dg=RKADxy_TVA@mail.gmail.com>
 <20200402152831.GA31612@gardel-login>
 <CAJfpegum_PsCfnar8+V2f_VO3k8CJN1LOFJV5OkHRDbQKR=EHg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAJfpegum_PsCfnar8+V2f_VO3k8CJN1LOFJV5OkHRDbQKR=EHg@mail.gmail.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Do, 02.04.20 17:35, Miklos Szeredi (miklos@szeredi.hu) wrote:

> > systemd cares about all mount points in PID1's mount namespace.
> >
> > The fact that mount tables can grow large is why we want something
> > better than constantly reparsing the whole /proc/self/mountinfo. But
> > filtering subsets of that is something we don't really care about.
>
> I can accept that, but you haven't given a reason why that's so.
>
> What does it do with the fact that an automount point was crossed, for
> example?  How does that affect the operation of systemd?

We don't care how a mount point came to be. If it's autofs or
something else, we don't care. We don't access these mount points
ourselves ever, we just watch their existance.

I mean, it's not just about startup it's also about shutdown. At
shutdown we need to unmount everything from the leaves towards the
root so that all file systems are in a clean state. And that means
*all* mounts, even autofs ones, even udisks ones, or whatever else
established them, we don't care. I mean, the autofs daemon can die any
time, we still must be able to sensibly shutdown, and thus unmount all
mounts inside some autofs hierarchy at the right time, before
unmounting the autofs top-level dir and then what might be further up
the tree.

systemd needs to know the whole tree, to figure out deps properly for
things like that, hence we aren't interested in filtering, we are
interested in minimizing what we do when something changes.

Lennart

--
Lennart Poettering, Berlin