[LU-9937] Re-order inode_lock and lli_trunc_sem to fix pio deadlock

Sat, 29 Jan 2022 10:46:35 +0000

When using pio, we take the inode lock in ll_file_io_generic. Unfortunately, this violates the expected ordering with lli_trunc_sem, as seen in vvp_io_setattr_

{start,end}

. This can result in a deadlock where a thread doing a write holds the inode lock and wants the trunc sem in read mode, but setattr already holds the trunc sem in write mode and wants the inode lock.

It appears to be safe to change the ordering between inode_lock and the lli_trunc_sem, so we always take the inode lock first.

Also, the forthcoming patch cleans up inode locking with pio, removing lli_inode_locked. The inode info is shared between all threads doing i/o on that inode, so usage of this meant we would not take the inode lock for operations that needed it if someone already held it (notably ll_fsync), and we would also let other threads unlock the inode lock for us.

So operations that expect complete coverage could get unlocked at some random point in their operation. Also, if a pio were holding the inode lock, multiple ll_fsync operations could occur at the same time.

Whamcloud Community JIRA

[LU-9937] Re-order inode_lock and lli_trunc_sem to fix pio deadlock