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
