From: "Theodore Ts'o" <tytso@mit.edu>
To: Ye Bin <yebin10@huawei.com>
Cc: adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC] ext4: Fix fs can't panic when abort by user
Date: Fri, 9 Apr 2021 17:28:54 -0400 [thread overview]
Message-ID: <YHDHFv99m3A6jQjP@mit.edu> (raw)
In-Reply-To: <20210401081903.3421208-1-yebin10@huawei.com>
On Thu, Apr 01, 2021 at 04:19:03PM +0800, Ye Bin wrote:
> Test steps:
> 1. mount /dev/sda -o errors=panic test
> 2. mount /dev/sda -o remount,ro test
> 3. mount /dev/sda -o remount,abort test
>
> Before 014c9caa29d3 not been merged there will trigger panic. But
> 014c9caa29d3 change this behavior.
This makes sense, but I'll note this behavior has changed over time.
root@kvm-xfstests:~# mount -o errors=panic /dev/vdc /vdc
[ 20.252713] EXT4-fs (vdc): mounted filesystem with ordered data mode. Opts: errors=panic
root@kvm-xfstests:~# mount -o remount,ro /dev/vdc
[ 24.832448] EXT4-fs (vdc): re-mounted. Opts: (null)
root@kvm-xfstests:~# mount -o remount,abort /dev/vdc
[ 30.833543] EXT4-fs error (device vdc): ext4_remount:5340: Abort forced by user
mount: /vdc: cannot remount /dev/vdc read-write, is write-protected.
root@kvm-xfstests:~# mount -o remount,abort,ro /dev/vdc
[ 34.545549] EXT4-fs error (device vdc): ext4_remount:5340: Abort forced by user
[ 34.555475] EXT4-fs (vdc): re-mounted. Opts: abort
root@kvm-xfstests:~# uname -a
Linux kvm-xfstests 4.19.163-xfstests #1 SMP Sat Dec 19 23:55:11 EST 2020 x86_64 GNU/Linux
root@kvm-xfstests:~#
The same is true for the 5.4 kernel.
I do agree that it *should* force a panic, and the fact that
superblock is read-only shouldn't make a difference as to how
errors=panic is handled.
So I think the patch is correct, but I'll note that it also changes
this case:
1) mount -o /dev/sda -o ro,errors=panic test
2) echo test > /sys/fs/ext4/sda/trigger_fs_error
With this patch, this will also now panic, whereas before, an
ext4_error() would not trigger a panic. I think that's better because
it makes things more consistent --- but it is a change in behavior
which could potentially surprise some people. But since they can
easily get the previous behavior with an explicit "mount -o
ro,errors=continue", I think that's acceptable.
I'll apply the patch with a modified commit description to warn of
this particular change in behavior.
- Ted
next prev parent reply other threads:[~2021-04-09 21:29 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-01 8:19 [RFC] ext4: Fix fs can't panic when abort by user Ye Bin
2021-04-09 21:28 ` Theodore Ts'o [this message]
2021-04-09 22:41 ` Theodore Ts'o
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=YHDHFv99m3A6jQjP@mit.edu \
--to=tytso@mit.edu \
--cc=adilger.kernel@dilger.ca \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@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 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.