On Wed, Dec 11, 2024 at 11:35:40PM -0800, Christoph Hellwig wrote: > On Thu, Dec 12, 2024 at 12:37:39AM -0500, Theodore Ts'o wrote: > > More generally, any file system which uses the buffer cache, and > > doesn't use jbd2 to control when writeback happens, I think is going > > to be at risk with a block device which requires stable writes. The > > only way to fix this, really, is to have the buffer cache code copy > > the data to a bounce buffer, and then issue the write from the bounce > > buffer. > > Should there be a pr_warn_once when using a file systems using the legacy > buffer cache interfaces on a device that requires stable pages? Well, either that, or we need to teach the buffer cache writeback code to issue writes through a bounce buffer if the device requires stable writes. I'll note that this could also manifest if some program was writing to a device that requires stable writes using buffered I/O. For example, if they are using postgres, which won't be switching to direct I/O for another 2-5 years (depending on how optimistic you are and how willing enterprise customers will be to move to the latest version of Postgres; some are stillu using very ancient Postgres for the same reason that RHEL 7 systems based on the 3.10 kernel are still in production use even today.) For this particular use case, which is running VM's on Chromium/ChromeOS, I suspect we do need to have some kind of solution other than triggering a WARN_ON. Besides, I'd really rather not get the kind of syzbot noise we would have by having some scheme that would be trivially easy for syzbot to trigger. (We're not should use WARN_ON for things that can be triggered by Stupid User Tricks, because syzbot fuzzers can be so ingenious. :-) - Ted
