linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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: Thu, 17 Aug 2023 22:10:38 -0400	[thread overview]
Message-ID: <20230818021038.GC3464136@mit.edu> (raw)
In-Reply-To: <20230817164739.GC1483@sol.localdomain>

On Thu, Aug 17, 2023 at 09:47:39AM -0700, Eric Biggers wrote:
> 
> Eric S. is correct that for a filesystem image to enable panic on error, support
> for panic on error should have to be properly consented to by the kernel
> configuration, for example through an fs.allow_panic_on_error sysctl.

I disagree.  It's up to the system administrator, not the kernel ---
and the system adminsitrator is perfectly free to run e2fsck on a
random file system, or to use tune2fs to adjust the panic on error
setting on the file system, befure using their root powers to mount
the file system.

Root can do many things that cause the system to reboot.  For example,
the system adminsirtator could run /sbin/reboot.  Should the kernel
"consent" by setting fs.allow_reboot_system_call_to_work before the
root user can run the /sbin/reboot binary?  Hopefully it's obvious why
this makes absolutely no sense.

> It can be argued that this not important, or not worth implementing when the
> default will need to remain 1 for backwards compatibility.  Or even that
> syzkaller should work around it in the mean time.  But it is incorrect to write
> "This is fundamentally a syzbot bug."

Well, the current behaviour is Working as Intended.  And if syzbot is
going about whining about things that are Working as Intended, it's
not fit for the upostream developers' purpose.

As another example, root can set a real-time priority of a process to
be at a level where it will prempt all other processes, including
kernel threads.  Do enough of these, and you *will* lock up the
kernel.  Again, should there be a sysctl that allows real-time
priorities to work?  Or do we teach syzbot that doing things that are
documented to cause the kernel to lock up are not something that's
worthy of a report.  In the past, syzbot issued a *huge* amount of
noise caused by precisely to this.  Upstream developers complained
that it was a false positive, and syzbot was adjusted to Stop Doing
That.

						- Ted

  reply	other threads:[~2023-08-18  2:11 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 [this message]
2023-08-18  2:52           ` Eric Biggers
2023-08-18 14:25             ` 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=20230818021038.GC3464136@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 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).