[LU-4152] layout locks can cause deadlock

• Type: Bug
• Resolution: Fixed
• Priority: Blocker
• Fix Version/s: Lustre 2.6.0, Lustre 2.5.1
• Affects Version/s: Lustre 2.5.0, Lustre 2.6.0
• Labels: HSM
• Environment: le
• Severity: 3
• Assignee: Oleg Drokin
• Reporter: Andriy Skulysh

Description

LU-1876 adds mdt_object_open_lock() which acquires lock in 2 steps for layout locks.
A deadlock is possible since it isn't atomic and ibits locks are reprocessed until first blocking lock found.

Such situation was hit with mdt_reint_open() & mdt_intent_getattr()

mdt_reint_open()->mdt_open_by_fid_lock() takes first part of the lock (ibits=5),
mdt_intent_getattr() tries to obtain lock (ibits=17)
mdt_open_by_fid_lock() tries to obtain second part but fails due to some conflict with another layout lock2. During cancellation of lock2 only getattr lock is reprocessed.
http://review.whamcloud.com/#/c/7148/1 can help, but it is better to fix mdt_open_by_fid_lock()

Issue Links

• is duplicated by: LU-3601 HSM release causes running restore to hang, hangs itself
• is related to: LU-4398 mdt_object_open_lock() may not flush conflicting handles
• is related to: LU-3601 HSM release causes running restore to hang, hangs itself
• is related to: LU-6015 mds evicting clients - lock timed out?
• is related to: LU-1876 Layout Lock Server Patch Landings to Master