On Tue, Jun 13, 2023 at 08:49:38AM +0200, Dmitry Vyukov wrote: > On Mon, 12 Jun 2023 at 18:16, Jan Kara <jack@xxxxxxx> wrote: > > > > Writing to mounted devices is dangerous and can lead to filesystem > > corruption as well as crashes. Furthermore syzbot comes with more and > > more involved examples how to corrupt block device under a mounted > > filesystem leading to kernel crashes and reports we can do nothing > > about. Add config option to disallow writing to mounted (exclusively > > open) block devices. Syzbot can use this option to avoid uninteresting > > crashes. Also users whose userspace setup does not need writing to > > mounted block devices can set this config option for hardening. > > +syzkaller, Kees, Alexander, Eric > > We can enable this on syzbot, however I have the same concerns as with > disabling of XFS_SUPPORT_V4: > https://github.com/google/syzkaller/issues/3918#issuecomment-1560624278 Really? This is exactly what I *detest most* about syzbot: the recalcitrant maintainer who thinks their ideology is more important than any other engineering consideration that might exist. We want *better quality bug reports* on *current code* that we have to *support for the foreseeable future*, not get buried under repeated shitty reports containing yet more variants of problems we fixed over a decade ago. I'll repeat what Eric has already pointed out in the above GH issue in the vain hope you'll listen this time rather than making even more extreme ideological demands on us. The XFS engineers put in place a planned, well documented deprecation and removal process for V4 format support back in 2020. We are well into that plan - we are not that far from turning it off v4 support by default. The V4 format is legacy code and users are already migrating away from it. As such, it has much lower priority and relevance to us compared to supporting v5 filesystems. The syzbot maintainers don't get to decide how important XFS v4 format support is - that's the job of the XFS engineers responsibile for developing XFS code and supporting XFS users. Because V4 has been deprecated and support is slowing down as people migrate off it, we don't need as extensive test coverage as we once did. i.e. we are ramping down the validation in accordance with it's lower priority and approaching disabling in 2025. We are placing much more importance on validation of v5 format features and functionality. As such, we really don't need syzbot to be exercising v4 formats any more - it's much more important to our users that we exercise v5 formats as extensively as possible. That is what we are asking the syzkaller runners (and syzbot) do as a service for us. If your ideology demands that "the only way to stop syzbot testing XFS v4 filesytsems is to remove the code entirely" (paraphrasing your comments from the above github issue), then the entire problem here is your ideology. That is, your ideology is getting in the way of practical, well thought out, long running end-of-life engineering processes. It is creating unnecessary load on limited resources. Further, your demands that we place syzbot coverage (if syzbot doesn't test it, it must depend on CONFIG_INSECURE!) above our direct responsibilities to distro maintainers and other downstream users is, at best, terribly misguided. Syzbot is a *tool*. It's not even a critical tool we depend on - we can live without it just fine. We'd really like syzbot to be a better tool, but the ideology behind syzbot is the biggest impediment to making it a better, more effective tool for the community. If syzbot maintainers won't listen to simple requests to improve test coverage according to subsystem requirements, then it's clear that syzbot is being driven by ideology rather than engineering requirements. This needs to change. -Dave. -- Dave Chinner david@xxxxxxxxxxxxx
