linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Theodore Ts'o <tytso@mit.edu>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
	"Aleksa Sarai" <asarai@suse.de>,
	"Luis R. Rodriguez" <mcgrof@kernel.org>,
	"Михаил Гаврилов" <mikhail.v.gavrilov@gmail.com>,
	"Christoph Hellwig" <hch@infradead.org>,
	"Jan Blunck" <jblunck@infradead.org>,
	linux-mm@kvack.org, "Oscar Salvador" <osalvador@suse.com>,
	"Jan Kara" <jack@suse.cz>, "Hannes Reinecke" <hare@suse.de>,
	linux-xfs@vger.kernel.org
Subject: Re: kernel BUG at fs/xfs/xfs_aops.c:853! in kernel 4.13 rc6
Date: Tue, 17 Oct 2017 09:00:11 +1100	[thread overview]
Message-ID: <20171016220010.GI15067@dastard> (raw)
In-Reply-To: <20171016011301.dcam44qylno7rm6a@thunk.org>

On Sun, Oct 15, 2017 at 09:13:01PM -0400, Theodore Ts'o wrote:
> On Sun, Oct 15, 2017 at 05:14:41PM -0500, Eric W. Biederman wrote:
> > 
> > Looking at the code it appears ext4, f2fs, and xfs shutdown path
> > implements revoking a bdev from a filesystem.  Further if the ext4
> > implementation is anything to go by it looks like something we could
> > generalize into the vfs.
> 
> There are two things which the current file system shutdown paths do.
> The first is that they prevent the file system from attempting to
> write to the bdev.  That's all very file system specific, and can't be
> generalized into the VFS.
> 
> The second thing they do is they cause system calls which might modify
> the file system to return an error.  Currently operations that might
> result in _reads_ are not shutdown, so it's not a true revoke(2)

Which is different to XFS - XFS shuts down all access to the bdev,
read or write, and returns EIO to the callers.(*) IOWs, a UAPI has
been copy-and-pasted, but the behaviour and semantics have not been
copied/duplicated. The requirement was "close enough for fstests to
use it" not "must behave the exact same way on all filesystems".

>From that perspective, I agree with Ted:  we need an interface
that provides userspace with sane, consistent semantics and allows
filesystems to be disconnected from userspace references so can be
unmounted. What the filesystem then does to disconnect itself from
the block device and allow unmount to complete (i.e. the shutdown
implementation) is irrelevant to the VFS and users....

Cheers,

Dave.

(*) Shutdown in XFS is primarily intended to prevent propagating
damage in the filesystem when corruption is first detected or an
unrecoverable error occurs. Historically speaking, it is always
initiated by the XFS filesystem itself, so whatever we do to provide
unmount sanity isn't going to replace internal filesystem shutdown
functionality...

-- 
Dave Chinner
david@fromorbit.com

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  parent reply	other threads:[~2017-10-16 22:00 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CABXGCsOL+_OgC0dpO1+Zeg=iu7ryZRZT4S7k-io8EGB0ZRgZGw@mail.gmail.com>
2017-09-03  7:43 ` kernel BUG at fs/xfs/xfs_aops.c:853! in kernel 4.13 rc6 Christoph Hellwig
2017-09-03 14:08   ` Михаил Гаврилов
2017-09-04 12:30     ` Jan Kara
2017-10-07  8:10       ` Михаил Гаврилов
2017-10-07  9:22         ` Михаил Гаврилов
2017-10-09  0:05         ` Dave Chinner
2017-10-09 18:31           ` Luis R. Rodriguez
2017-10-09 19:02             ` Eric W. Biederman
2017-10-15  8:53               ` Aleksa Sarai
2017-10-15 13:06                 ` Theodore Ts'o
2017-10-15 22:14                   ` Eric W. Biederman
2017-10-15 23:22                     ` Dave Chinner
2017-10-16 17:44                       ` Eric W. Biederman
2017-10-16 21:38                         ` Dave Chinner
2017-10-16  1:13                     ` Theodore Ts'o
2017-10-16 17:53                       ` Eric W. Biederman
2017-10-16 18:50                         ` Theodore Ts'o
2017-10-16 22:00                       ` Dave Chinner [this message]
2017-10-17  1:34                         ` Theodore Ts'o
2017-10-17  0:59                       ` Aleksa Sarai
2017-10-17  9:20                         ` Jan Kara
2017-10-17 14:12                           ` Theodore Ts'o
2017-11-06 19:25                             ` Luis R. Rodriguez
2017-11-07 15:26                               ` Jan Kara
2017-10-09 22:28             ` Dave Chinner
2017-10-10  7:57               ` Jan Kara
2017-09-04  1:43   ` Dave Chinner
2017-09-04  2:20     ` Darrick J. Wong
2017-09-04 12:14       ` Jan Kara
2017-09-04 22:36         ` Dave Chinner
2017-09-05 16:17           ` Jan Kara
2017-09-05 23:42             ` Dave Chinner

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=20171016220010.GI15067@dastard \
    --to=david@fromorbit.com \
    --cc=asarai@suse.de \
    --cc=ebiederm@xmission.com \
    --cc=hare@suse.de \
    --cc=hch@infradead.org \
    --cc=jack@suse.cz \
    --cc=jblunck@infradead.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=mikhail.v.gavrilov@gmail.com \
    --cc=osalvador@suse.com \
    --cc=tytso@mit.edu \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).