On Mon 20-02-23 12:51:26, Linus Torvalds wrote: > On Fri, Feb 17, 2023 at 3:43 AM Jan Kara <jack@xxxxxxx> wrote: > > > > * One fix to mpage_writepages() on which other udf fixes depend > > I've pulled this, and this doesn't look *wrong* per se, but it really > didn't look like a bug in mpage_writepages() to me. > > The bug seems to be clearly in the filesystem not returning a proper > error code from its "->get_block()" function. > > If the VFS layer asks for block creation, and the filesystem returns > no error, but then a non-mapped result, that sounds like _clearly_ a > filesystem bug to me. I agree having saner way to pass information from ->get_block "I cannot write this buffer in the page but please keep writing other buffers in this page" to the VFS is desirable. But this "return unmapped buffer" hack is what happened to work for __block_write_full_page() since ages and I belive it was occasionally used by filesystems so that's why I've made mpage_writepages() compatible with this behavior. > Blaming mpage_writepages() seems entirely wrong. > > The extra sanity check in the vfs layer doesn't strike me as wrong, but ... > > Maybe it could have been a WARN_ON_ONCE() if "get_block(.., 1)" > returns success with an unmapped result? A cleanup in this area would be certainly good but maybe the energy is better invested in the attempt to make filesystems use iomap instead of get_block based interfaces? Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
