From: "Theodore Ts'o" <tytso@mit.edu>
To: Eric Biggers <ebiggers@kernel.org>
Cc: sandeen@redhat.com,
syzbot <syzbot+27eece6916b914a49ce7@syzkaller.appspotmail.com>,
adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
llvm@lists.linux.dev, nathan@kernel.org, ndesaulniers@google.com,
syzkaller-bugs@googlegroups.com, trix@redhat.com
Subject: Re: [syzbot] [ext4?] kernel panic: EXT4-fs (device loop0): panic forced after error (3)
Date: Fri, 18 Aug 2023 10:25:44 -0400 [thread overview]
Message-ID: <20230818142544.GA3513305@mit.edu> (raw)
In-Reply-To: <20230818025255.GA2175@sol.localdomain>
On Thu, Aug 17, 2023 at 07:52:55PM -0700, Eric Biggers wrote:
> Obviously it's up to the system administrator; that should have been clear since
> I suggested a sysctl. Sorry if I wasn't clear. The point is that there are
> certain conventions for what is allowed to break the safety guarantees that the
> kernel provides to userspace, which includes causing a kernel panic. Panics on
> various problems are configured by /proc/sys/kernel/panic_*. So having to
> opt-in to panic-on-error, or at least being able to opt-out, by setting a sysctl
> seems natural. Whereas having mount() being able to automatically panic the
> kernel with no way to opt-out seems like a violation of broader kernel
> conventions, even if it happens to be "working as intended" in the ext4 context.
The reason why a sysctl isn't really great is because the system
administrator might want to configure the behavior on a per-file
system basis. And you *can* configure it as a mount option, via
"mount -o errors=continue" or "mount -o "errors=panic". The
superblock setting is just the default if something isn't explicitly
specified as a mount option (either on the command line or in
/etc/fstab).
So mount does not "automatically" panic the kernel, and there are
*plenty* of ways to opt-out. You can use the mount option; you can
run "tune2fs -e continue"; you can just !@#!?! run fsck.ext4 before
mounting the file system. There are all ways of "opting out." Some
of them, such as the last, is even considered best practice --- just
as picking up a USB stick, or worse, a firewire drive, in a parking
lot, and *not* plugging it into your laptop is considered best practice.
- Ted
prev parent reply other threads:[~2023-08-18 14:27 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-16 22:48 [syzbot] [ext4?] kernel panic: EXT4-fs (device loop0): panic forced after error (3) syzbot
2023-08-17 14:21 ` Theodore Ts'o
2023-08-17 14:28 ` Aleksandr Nogikh
2023-08-17 14:45 ` Theodore Ts'o
2023-08-18 11:43 ` Aleksandr Nogikh
2023-08-18 16:46 ` Aleksandr Nogikh
2023-08-17 14:47 ` Eric Sandeen
2023-08-17 16:11 ` Theodore Ts'o
2023-08-17 16:47 ` Eric Biggers
2023-08-18 2:10 ` Theodore Ts'o
2023-08-18 2:52 ` Eric Biggers
2023-08-18 14:25 ` Theodore Ts'o [this message]
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=20230818142544.GA3513305@mit.edu \
--to=tytso@mit.edu \
--cc=adilger.kernel@dilger.ca \
--cc=ebiggers@kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=sandeen@redhat.com \
--cc=syzbot+27eece6916b914a49ce7@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
--cc=trix@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.