[Bug 263765] panic: ffs_sync: modification on read-only filesystem

From: <bugzilla-noreply_at_freebsd.org>
Date: Thu, 05 May 2022 01:03:32 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263765

--- Comment #3 from Konstantin Belousov <kib@FreeBSD.org> ---
I see, ffs_sbput() indeed clears the flag, but nothing syncs it with updates
to fs_fmod in ffs_alloc.c (just for example).  As result, if a block or inode
is allocated or freed after fs_fmod is cleared but before struct fs is copied
to the b_data of superblock in ffs_use_bwrite(), then we get fmod == 1 on disk.

I am not sure, perhaps this could be considered a bug.  If we really do not
want to see fmod == 1 on disk, then zeroing should be moved to the
ffs_use_bwrite() function, right before recalculation of the checksum.

More important, I believe, UFS mount lock should be taken around bcopy()
in ffs_use_bwrite(), although there is probably not too many volatile
fields which can be corrupted, if any.

I believe that zeroing in ffs_sbput() must be left for userspace consumers?

-- 
You are receiving this mail because:
You are the assignee for the bug.