ll_fsync is taking an inode mutex and then creates IO that might go into layout refresh that might take layout mutex and block for IOs to finish

write path might go into vvp_io_write_start with active IOs already incremented because IO was started and block on the locked inode held by ll_fsync.

Thus the deadlock.

It looks like we don't really need the inode lock held in ll_fsync at at least not for as much? the LU-812 does not go into a lot of explanations on the reasons behind adding the locking there.