lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z4cBRufxcp5izFWC@dread.disaster.area>
Date: Wed, 15 Jan 2025 11:28:54 +1100
From: Dave Chinner <david@...morbit.com>
To: Jinliang Zheng <alexjlzheng@...il.com>
Cc: chandan.babu@...cle.com, djwong@...nel.org, linux-xfs@...r.kernel.org,
	linux-kernel@...r.kernel.org, flyingpeng@...cent.com,
	Jinliang Zheng <alexjlzheng@...cent.com>
Subject: Re: [PATCH] xfs: using mutex instead of semaphore for xfs_buf_lock()

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ