From: Al Viro <viro@zeniv.linux.org.uk>
To: Mikulas Patocka <mpatocka@redhat.com>
Cc: Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
linux-kernel@vger.kernel.org, dm-devel@redhat.com,
Zdenek Kabelac <zkabelac@redhat.com>,
linux-fsdevel@vger.kernel.org, Christoph Hellwig <hch@lst.de>
Subject: Re: [dm-devel] [PATCH] fix writing to the filesystem after unmount
Date: Wed, 6 Sep 2023 18:08:56 +0100 [thread overview]
Message-ID: <20230906170856.GA800259@ZenIV> (raw)
In-Reply-To: <f5d63867-5b3e-294b-d1f5-a128817cfc7@redhat.com>
On Wed, Sep 06, 2023 at 05:03:34PM +0200, Mikulas Patocka wrote:
> > IOW, you'd also hang on any umount of a bind-mount. IOW, every
> > single container making use of this filesystems via bind-mounts would
> > hang on umount and shutdown.
>
> bind-mount doesn't modify "s->s_writers.frozen", so the patch does nothing
> in this case. I tried unmounting bind-mounts and there was no deadlock.
You are making *any* mount destruction hang if the sucker is frozen.
Which includes the things like exit(2) of the last process within
a namespace, etc.
And it does include the things like mount --bind /usr/bin/gcc /tmp/cc; umount /tmp/cc
if /usr happened to be frozen at the moment.
This is really not an option.
> BTW. what do you think that unmount of a frozen filesystem should properly
> do? Fail with -EBUSY? Or, unfreeze the filesystem and unmount it? Or
> something else?
It's not just umount(2). It's exit(2). And close(2). And AF_UNIX garbage
collector taking out an undeliverable SCM_RIGHTS datagram that happens to
contain a reference to the last opened file on lazy-umounted fs, etc.
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
WARNING: multiple messages have this Message-ID (diff)
From: Al Viro <viro@zeniv.linux.org.uk>
To: Mikulas Patocka <mpatocka@redhat.com>
Cc: Christian Brauner <brauner@kernel.org>,
Zdenek Kabelac <zkabelac@redhat.com>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
dm-devel@redhat.com, Jan Kara <jack@suse.cz>,
Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH] fix writing to the filesystem after unmount
Date: Wed, 6 Sep 2023 18:08:56 +0100 [thread overview]
Message-ID: <20230906170856.GA800259@ZenIV> (raw)
In-Reply-To: <f5d63867-5b3e-294b-d1f5-a128817cfc7@redhat.com>
On Wed, Sep 06, 2023 at 05:03:34PM +0200, Mikulas Patocka wrote:
> > IOW, you'd also hang on any umount of a bind-mount. IOW, every
> > single container making use of this filesystems via bind-mounts would
> > hang on umount and shutdown.
>
> bind-mount doesn't modify "s->s_writers.frozen", so the patch does nothing
> in this case. I tried unmounting bind-mounts and there was no deadlock.
You are making *any* mount destruction hang if the sucker is frozen.
Which includes the things like exit(2) of the last process within
a namespace, etc.
And it does include the things like mount --bind /usr/bin/gcc /tmp/cc; umount /tmp/cc
if /usr happened to be frozen at the moment.
This is really not an option.
> BTW. what do you think that unmount of a frozen filesystem should properly
> do? Fail with -EBUSY? Or, unfreeze the filesystem and unmount it? Or
> something else?
It's not just umount(2). It's exit(2). And close(2). And AF_UNIX garbage
collector taking out an undeliverable SCM_RIGHTS datagram that happens to
contain a reference to the last opened file on lazy-umounted fs, etc.
next prev parent reply other threads:[~2023-09-06 17:09 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-06 13:26 [dm-devel] [PATCH] fix writing to the filesystem after unmount Mikulas Patocka
2023-09-06 13:26 ` Mikulas Patocka
2023-09-06 14:27 ` [dm-devel] " Christian Brauner
2023-09-06 14:27 ` Christian Brauner
2023-09-06 15:03 ` [dm-devel] " Mikulas Patocka
2023-09-06 15:03 ` Mikulas Patocka
2023-09-06 15:33 ` [dm-devel] " Christian Brauner
2023-09-06 15:33 ` Christian Brauner
2023-09-06 15:58 ` [dm-devel] " Christian Brauner
2023-09-06 15:58 ` Christian Brauner
2023-09-06 16:01 ` [dm-devel] " Mikulas Patocka
2023-09-06 16:01 ` Mikulas Patocka
2023-09-06 16:19 ` [dm-devel] " Christian Brauner
2023-09-06 16:19 ` Christian Brauner
2023-09-06 16:52 ` [dm-devel] " Mikulas Patocka
2023-09-06 16:52 ` Mikulas Patocka
2023-09-07 9:44 ` [dm-devel] " Jan Kara
2023-09-07 9:44 ` Jan Kara
2023-09-07 10:43 ` [dm-devel] " Christian Brauner
2023-09-07 10:43 ` Christian Brauner
2023-09-07 12:04 ` [dm-devel] " Mikulas Patocka
2023-09-07 12:04 ` Mikulas Patocka
2023-09-08 7:32 ` [dm-devel] " Jan Kara
2023-09-08 7:32 ` Jan Kara
2023-09-08 9:29 ` [dm-devel] " Zdenek Kabelac
2023-09-08 9:29 ` Zdenek Kabelac
2023-09-08 10:20 ` [dm-devel] " Jan Kara
2023-09-08 10:20 ` Jan Kara
2023-09-08 10:51 ` [dm-devel] " Zdenek Kabelac
2023-09-08 11:32 ` Christian Brauner
2023-09-08 11:32 ` Christian Brauner
2023-09-08 12:07 ` [dm-devel] " Zdenek Kabelac
2023-09-08 12:07 ` Zdenek Kabelac
2023-09-08 12:07 ` [dm-devel] " Zdenek Kabelac
2023-09-08 12:34 ` Christian Brauner
2023-09-08 12:34 ` Christian Brauner
2023-09-12 9:10 ` [dm-devel] " Jan Kara
2023-09-12 9:10 ` Jan Kara
2023-09-08 12:02 ` [dm-devel] " Christian Brauner
2023-09-08 12:02 ` Christian Brauner
2023-09-08 16:49 ` [dm-devel] " John Stoffel
2023-09-08 16:49 ` John Stoffel
2023-09-09 11:21 ` [dm-devel] " Christoph Hellwig
2023-09-09 11:21 ` Christoph Hellwig
2023-09-08 12:01 ` [dm-devel] " Pavel Machek
2023-09-08 12:01 ` Pavel Machek
2023-09-08 11:59 ` [dm-devel] " Pavel Machek
2023-09-08 11:59 ` Pavel Machek
2023-09-06 17:10 ` [dm-devel] " Al Viro
2023-09-06 17:10 ` Al Viro
2023-09-06 17:08 ` Al Viro [this message]
2023-09-06 17:08 ` Al Viro
2023-09-06 15:22 ` [dm-devel] " Darrick J. Wong
2023-09-06 15:22 ` Darrick J. Wong
2023-09-06 15:38 ` [dm-devel] " Christian Brauner
2023-09-06 15:38 ` Christian Brauner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230906170856.GA800259@ZenIV \
--to=viro@zeniv.linux.org.uk \
--cc=brauner@kernel.org \
--cc=dm-devel@redhat.com \
--cc=hch@lst.de \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mpatocka@redhat.com \
--cc=zkabelac@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.