On Fri, Dec 20, 2024 at 01:16:29AM +0800, Jinliang Zheng wrote: > xfs_buf uses a semaphore for mutual exclusion, and its count value > is initialized to 1, which is equivalent to a mutex. > > However, mutex->owner can provide more information when analyzing > vmcore, making it easier for us to identify which task currently > holds the lock. However, the buffer lock also protects the buffer state and contents whilst IO id being performed and it *is not owned by any task*. A single lock cycle for a buffer can pass through multiple tasks before being unlocked in a different task to that which locked it: p0 <intr> <kworker> xfs_buf_lock() ... <submitted for async io> <wait for IO completion> ..... <io completion> queued to workqueue ..... perform IO completion xfs_buf_unlock() IOWs, the buffer lock here prevents any other task from accessing and modifying the contents/state of the buffer until the IO in flight is completed. i.e. the buffer contents are guaranteed to be stable during write IO, and unreadable when uninitialised during read IO.... i.e. the locking model used by xfs_buf objects is incompatible with the single-owner-task critical section model implemented by mutexes... -Dave. -- Dave Chinner david@xxxxxxxxxxxxx
