On Wed, Nov 15, 2023 at 11:01:39AM +0200, Amir Goldstein wrote: > On Wed, Nov 15, 2023 at 1:42 AM Jan Harkes <jaharkes@xxxxxxxxxx> wrote: > > * Since freeze protection behaves as a lock, users have to preserve > > * ordering of freeze protection and other filesystem locks. Generally, > > * freeze protection should be the outermost lock. In particular, we > > * have: > > * > > * sb_start_write > > * -> i_mutex (write path, truncate, directory ops, > > * ...) > > * -> s_umount (freeze_super, thaw_super) > > > > This describes the locking order within a specific fs. > host_file is not in the same fs as code_inode. > > IIUC, host_file is a sort of backing file for the code inode. > In cases like this, as in cachefiles and overlayfs, it is best > to order all backing fs locks strictly after all the frontend fs locks. > See ovl_write_iter() for example. > > IOW, the new lock ordering is preferred: > file_start_write(coda_file) > inode_lock(code_inode) > file_start_write(host_file) > inode_lock(host_inode) Well, if everybody else is doing it, I guess it must be ok. Jan
