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
