Re: [PATCH] xfs: using mutex instead of semaphore for xfs_buf_lock()

[Dave Chinner <david@fromorbit.com>]

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@fromorbit.com