From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id CB41CC001DF for ; Wed, 2 Aug 2023 20:17:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229632AbjHBURE (ORCPT ); Wed, 2 Aug 2023 16:17:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57800 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229547AbjHBURB (ORCPT ); Wed, 2 Aug 2023 16:17:01 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D4AA92689 for ; Wed, 2 Aug 2023 13:16:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1691007379; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=0XIGrFGP7J2HGVDS8S1Cuzs5GSwXNIGvY43RGd9K/2A=; b=YzGdGVLe6M+WZi2Dk/zhFn8vu7AiEAqMJX6T/2S1/10HFB+u4jE8DFoZWlF87qip3z8YE+ kZRn2dauyAS8tURqquj6ZtDjdq4/aCRFN4jE5/BULcBEU62jXlT1St2HHxDqdgioNZvF3R +AS0rEthYRPTrRc1Qm5gR06qgKYnom8= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-224-9AZaV10IMy2zzJtrak0OJw-1; Wed, 02 Aug 2023 16:16:13 -0400 X-MC-Unique: 9AZaV10IMy2zzJtrak0OJw-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 5BA28185A792; Wed, 2 Aug 2023 20:16:13 +0000 (UTC) Received: from [10.22.18.41] (unknown [10.22.18.41]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0C10E200A7CA; Wed, 2 Aug 2023 20:16:13 +0000 (UTC) Message-ID: Date: Wed, 2 Aug 2023 16:16:12 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Subject: Re: [PATCH 11/20] locking/osq: Export osq_(lock|unlock) Content-Language: en-US To: Kent Overstreet , linux-bcachefs@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Peter Zijlstra , Ingo Molnar , Boqun Feng References: <20230712211115.2174650-1-kent.overstreet@linux.dev> <20230712211115.2174650-12-kent.overstreet@linux.dev> From: Waiman Long In-Reply-To: <20230712211115.2174650-12-kent.overstreet@linux.dev> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 3.1 on 10.11.54.4 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 7/12/23 17:11, Kent Overstreet wrote: > These are used by bcachefs's six locks. > > Signed-off-by: Kent Overstreet > Cc: Peter Zijlstra > Cc: Ingo Molnar > Cc: Waiman Long > Cc: Boqun Feng > --- > 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