Re: [syzbot] [ext4?] kernel panic: EXT4-fs (device loop0): panic forced after error (3)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux