vx_rwsleep_lock
vx_iplock
vx_write_advise <<< write advise
vx_write_common
vx_rdwr_attr
vnop_rdwr
vno_rw
rwuio
rdwr
kewrite
syscall
vx_ilock
vx_idalloc_flush
vx_idalloc_off
vx_dalloc_flush <<< dalloc
vx_workitem_process
vx_worklist_process
vx_worklist_thread
mutex_lock
vx_ilock
vx_dalloc_do_flush_file
vx_dalloc_flush <<< dalloc
vx_workitem_process
vx_worklist_process
vx_worklist_thread
vx_kthread_init
kernel_thread_helper
This occurs while two threads contest for two locks: ILOCK and PLOCK.
The "write advise" thread, with the above stack, owns the ILOCK, but is waiting for the PLOCK. The dalloc thread owns the PLOCK and is waiting for the ILOCK with above stack.
This deadlock is caused by an incorrect locking order between the "write advise" thread and "dalloc flusher" thread. This causes file system commands, like df, or umount, to stop responding, or "hang."
Veritas engineering has updated the code to correct the order of locking, to avoid the deadlock between the threads.
This issue is fixed in these VxFS patches:
The issue is also fixed in Storage Foundation High Availability (SFHA) patch 6.1.1.100 SLES11SP4 specific release:
sfha-sles11sp4_x86_64-Patch-6.1.1.100
Patches are available from Veritas SORT:
https://sort.veritas.com/patch/finder
The following hotfixes are also available. Please contact Veritas technical support if the following hotfixes are required:
VxFS 6.1.1:
VxFS 6.0.5: