From: Christoph Hellwig <hch@infradead.org>
To: Jan Kara <jack@suse.cz>
Cc: linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org,
linux-block@vger.kernel.org,
Christoph Hellwig <hch@infradead.org>, yebin <yebin10@huawei.com>,
Andreas Dilger <adilger@dilger.ca>, Jens Axboe <axboe@kernel.dk>,
stable@vger.kernel.org
Subject: Re: [PATCH 1/2] fs: Don't invalidate page buffers in block_write_full_page()
Date: Mon, 7 Sep 2020 08:12:28 +0100 [thread overview]
Message-ID: <20200907071228.GA27898@infradead.org> (raw)
In-Reply-To: <20200904085852.5639-2-jack@suse.cz>
On Fri, Sep 04, 2020 at 10:58:51AM +0200, Jan Kara wrote:
> If block_write_full_page() is called for a page that is beyond current
> inode size, it will truncate page buffers for the page and return 0.
> This logic has been added in 2.5.62 in commit 81eb69062588 ("fix ext3
> BUG due to race with truncate") in history.git tree to fix a problem
> with ext3 in data=ordered mode. This particular problem doesn't exist
> anymore because ext3 is long gone and ext4 handles ordered data
> differently. Also normally buffers are invalidated by truncate code and
> there's no need to specially handle this in ->writepage() code.
>
> This invalidation of page buffers in block_write_full_page() is causing
> issues to filesystems (e.g. ext4 or ocfs2) when block device is shrunk
> under filesystem's hands and metadata buffers get discarded while being
> tracked by the journalling layer. Although it is obviously "not
> supported" it can cause kernel crashes like:
Btw, while looking over the block device revalidation code I think
all the magic we do on shrinking block devices actually is a bad
idea - potentially very harmful, but without much real benefit.
And it only is run on file systems directly created on the whole device,
meaning it isn't even used at all with the typical setups that use
partitions.
Anyway, this patch looks good:
Reviewed-by: Christoph Hellwig <hch@lst.de>
next prev parent reply other threads:[~2020-09-07 7:12 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-04 8:58 [PATCH 0/2 v2] bdev: Avoid discarding buffers under a filesystem Jan Kara
2020-09-04 8:58 ` [PATCH 1/2] fs: Don't invalidate page buffers in block_write_full_page() Jan Kara
2020-09-07 7:12 ` Christoph Hellwig [this message]
2020-09-04 8:58 ` [PATCH 2/2] block: Do not discard buffers under a mounted filesystem Jan Kara
2020-09-07 7:12 ` Christoph Hellwig
2020-09-07 10:35 ` [PATCH 0/2 v2] bdev: Avoid discarding buffers under a filesystem Jan Kara
2020-09-07 16:24 ` Jens Axboe
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=20200907071228.GA27898@infradead.org \
--to=hch@infradead.org \
--cc=adilger@dilger.ca \
--cc=axboe@kernel.dk \
--cc=jack@suse.cz \
--cc=linux-block@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=yebin10@huawei.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 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).