Re: [PATCH 11/20] locking/osq: Export osq_(lock|unlock)

From: Waiman Long
Date: Wed Aug 02 2023 - 16:17:05 EST


On 7/12/23 17:11, Kent Overstreet wrote:
These are used by bcachefs's six locks.

Signed-off-by: Kent Overstreet <kent.overstreet@xxxxxxxxx>
Cc: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
Cc: Ingo Molnar <mingo@xxxxxxxxxx>
Cc: Waiman Long <longman@xxxxxxxxxx>
Cc: Boqun Feng <boqun.feng@xxxxxxxxx>
---
kernel/locking/osq_lock.c | 2 ++
1 file changed, 2 insertions(+)

diff --git a/kernel/locking/osq_lock.c b/kernel/locking/osq_lock.c
index d5610ad52b..b752ec5cc6 100644
--- a/kernel/locking/osq_lock.c
+++ b/kernel/locking/osq_lock.c
@@ -203,6 +203,7 @@ bool osq_lock(struct optimistic_spin_queue *lock)
return false;
}
+EXPORT_SYMBOL_GPL(osq_lock);
void osq_unlock(struct optimistic_spin_queue *lock)
{
@@ -230,3 +231,4 @@ void osq_unlock(struct optimistic_spin_queue *lock)
if (next)
WRITE_ONCE(next->locked, 1);
}
+EXPORT_SYMBOL_GPL(osq_unlock);

Have you considered extending the current rw_semaphore to support a SIX lock semantics? There are a number of instances in the kernel that a up_read() is followed by a down_write(). Basically, the code try to upgrade the lock from read to write. I have been thinking about adding a upgrade_read() API to do that. However, the concern that I had was that another writer may come in and make modification before the reader can be upgraded to have exclusive write access and will make the task to repeat what has been done in the read lock part. By adding a read with intent to upgrade to write, we can have that guarantee.

With that said, I would prefer to keep osq_{lock/unlock} for internal use by some higher level locking primitives - mutex, rwsem and rt_mutex.

Cheers,
Longman