Re: [PATCH v2] udf: Fix race between file type conversion and writeback

[Jan Kara <jack@suse.cz>]

On Wed 25-03-26 22:47:40, Christoph Hellwig wrote:
> On Wed, Mar 25, 2026 at 05:22:10PM +0100, Jan Kara wrote:
> > udf_setsize() can race with udf_writepages() as follows:
> > 
> > udf_setsize()			udf_writepages()
> > 				  if (iinfo->i_alloc_type ==
> > 						ICBTAG_FLAG_AD_IN_ICB)
> >   err = udf_expand_file_adinicb(inode);
> >   err = udf_extend_file(inode, newsize);
> > 				    udf_adinicb_writepages()
> > 				      memcpy_from_file_folio() - crash
> > 					because inode size is too big.
> > 
> > Fix the problem by rechecking file type under folio lock in
> > udf_writepages() which properly serializes with
> > udf_expand_file_adinicb(). Since it is quite difficult to implement this
> > locking with current writeback_iter() logic, let's just opencode the
> > logic necessary to prepare (the only) folio the inode can have for
> > writeback.
> 
> Still not a fan of open coding this logic, which is even worse than
> the previous export.  Inline data is a relatively common case in
> various file systems, and we should be able to handle it in common
> code.

I agree inline data is relatively common but as far as I was checking UDF
is the only filesystem using mpage_writepages() that is supporting inline
data (well, OCFS2 does as well but it doesn't bother with inline data
writeback - it handles only write(2) to files with inline data which modify
on disk content directly, they expand the file to extents in case of mmap).
So a special hook in mpage_writepages() for UDF looks like a bit of an
overkill to me.

> So having a callback in mpage_writepages seems much better,
> but if you detest that we could just export mpage_write_folio and
> mpage_bio_submit_write (and make mpage_data public) instead.  I think
> that's significantly worse than just adding the callback, but still
> much better than open coding more writeback internals, something I
> want to get away from.

I agree the callback is better than making all that mpage infrastructure
public. I still think exporting folio_prepare_writeback() would be less
burden than the callback but frankly I don't think it matters enough to
argue further. I just want to get that race fixed :).

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR