All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Jan Kara <jack@suse.cz>
Cc: Christian Brauner <brauner@kernel.org>,
	"Darrick J. Wong" <djwong@kernel.org>,
	linux-kernel@vger.kernel.org, dm-devel@redhat.com,
	Mikulas Patocka <mpatocka@redhat.com>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	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: Sat, 9 Sep 2023 13:21:47 +0200	[thread overview]
Message-ID: <20230909112147.GA12000@lst.de> (raw)
In-Reply-To: <20230908102014.xgtcf5wth2l2cwup@quack3>

On Fri, Sep 08, 2023 at 12:20:14PM +0200, Jan Kara wrote:
> Well, currently you click some "Eject / safely remove / whatever" button
> and then you get a "wait" dialog until everything is done after which
> you're told the stick is safe to remove. What I imagine is that the "wait"
> dialog needs to be there while there are any (or exclusive at minimum) openers
> of the device. Not until umount(2) syscall has returned. And yes, the
> kernel doesn't quite make that easy - the best you can currently probably
> do is to try opening the device with O_EXCL and if that fails, you know
> there's some other exclusive open.

... and the simple answer to the problem is to have an event notification
for when the super_block has finally been destroyed.  That way the
application gets this notification directly instead of having to make
a process synchronous that fundamentally isn't as explained in this thread.

--
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: Christoph Hellwig <hch@lst.de>
To: Jan Kara <jack@suse.cz>
Cc: Zdenek Kabelac <zkabelac@redhat.com>,
	Mikulas Patocka <mpatocka@redhat.com>,
	Christian Brauner <brauner@kernel.org>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	dm-devel@redhat.com, Christoph Hellwig <hch@lst.de>,
	"Darrick J. Wong" <djwong@kernel.org>
Subject: Re: [PATCH] fix writing to the filesystem after unmount
Date: Sat, 9 Sep 2023 13:21:47 +0200	[thread overview]
Message-ID: <20230909112147.GA12000@lst.de> (raw)
In-Reply-To: <20230908102014.xgtcf5wth2l2cwup@quack3>

On Fri, Sep 08, 2023 at 12:20:14PM +0200, Jan Kara wrote:
> Well, currently you click some "Eject / safely remove / whatever" button
> and then you get a "wait" dialog until everything is done after which
> you're told the stick is safe to remove. What I imagine is that the "wait"
> dialog needs to be there while there are any (or exclusive at minimum) openers
> of the device. Not until umount(2) syscall has returned. And yes, the
> kernel doesn't quite make that easy - the best you can currently probably
> do is to try opening the device with O_EXCL and if that fails, you know
> there's some other exclusive open.

... and the simple answer to the problem is to have an event notification
for when the super_block has finally been destroyed.  That way the
application gets this notification directly instead of having to make
a process synchronous that fundamentally isn't as explained in this thread.


  parent reply	other threads:[~2023-09-09 11:22 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                         ` Christoph Hellwig [this message]
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     ` [dm-devel] " Al Viro
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=20230909112147.GA12000@lst.de \
    --to=hch@lst.de \
    --cc=brauner@kernel.org \
    --cc=djwong@kernel.org \
    --cc=dm-devel@redhat.com \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mpatocka@redhat.com \
    --cc=viro@zeniv.linux.org.uk \
    --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.