From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from 011.lax.mailroute.net (011.lax.mailroute.net [199.89.1.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 76E0D21ABD7 for ; Tue, 5 May 2026 20:06:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=199.89.1.14 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778011567; cv=none; b=sgzA4nGav0D9dbFAJlPRe850jjlzm3cFsaYHq7qbOzHzIYuwSgXSwlI3+SgzBwqsdeV8kFEFH+GkO4bjd39zv1P9GTbpuQykPECmBA8pfdP6yw7k4STHjkof4ZRZbCdNdrauyzDAwKY29UA0oQsxEN6QM8GUi4oWN6Q0EKiQ8is= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778011567; c=relaxed/simple; bh=MQPo3rb0hCM085Kbu3yFA5SJNDs+WedtVnqjH+EzLds=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=B3ZVqLxFLDIyuL8m6Nh0bXNx2cctG4wHfy+yUfiG+FzT3uT9ceSBHn7XrnI/ma+cgznaZq7lqgkDXBXFcqvdJ9Yv7zfI1YYEYyFHsvXjzSEAjqVxJu8JcIZDEPZ7YDIdMAEZhOmK4P2IhZDNuQNptOp3YJsaav1F3xlFXLyYFHU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=acm.org; spf=pass smtp.mailfrom=acm.org; dkim=pass (2048-bit key) header.d=acm.org header.i=@acm.org header.b=WDjU1tvJ; arc=none smtp.client-ip=199.89.1.14 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=acm.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=acm.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=acm.org header.i=@acm.org header.b="WDjU1tvJ" Received: from localhost (localhost [127.0.0.1]) by 011.lax.mailroute.net (Postfix) with ESMTP id 4g98f56xhVz1XM5kD; Tue, 5 May 2026 20:06:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=acm.org; h= content-transfer-encoding:content-type:content-type:in-reply-to :from:from:content-language:references:subject:subject :user-agent:mime-version:date:date:message-id:received:received; s=mr01; t=1778011558; x=1780603559; bh=0h994xiK0Pq4iRHCfRUhSYfG QDYWYyKphPHQcoRlq/Y=; b=WDjU1tvJqO8NYYU/Dk1Ebp8pd9nFmGs7iJDvfmjJ uxoiigTDuZAtEGkkaLwbXaL5hryWkzMHcaNXN68Tz4sATyTYcbutjh6R5MYab4Rh 6Zblk6dGgGTCBvI57/M59ZZzOR3NqvG/HVVP0/i8peK+6Vwrt7NczBY+6/LepDTG PHA4gnDOSicq/OBoNgXNKqkWdjGtWw7jy4a50XvQ6SpkLDRiDDrNwxQFvswyn1Cd Y0FX23KGvAx3++2MBKeclNPWsEgO34jY+0NHnvdB6JKgf3iFvteE26pyjkbmQ8+n 8BbQJsoTvZrHNWo1o8scyu0FXbPShGgJrjLV7tD00kNxzg== X-Virus-Scanned: by MailRoute Received: from 011.lax.mailroute.net ([127.0.0.1]) by localhost (011.lax [127.0.0.1]) (mroute_mailscanner, port 10029) with LMTP id q2_KrCVobuNw; Tue, 5 May 2026 20:05:58 +0000 (UTC) Received: from [10.211.9.52] (unknown [213.147.98.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: bvanassche@acm.org) by 011.lax.mailroute.net (Postfix) with ESMTPSA id 4g98ds4Q7zz1XM5kY; Tue, 5 May 2026 20:05:53 +0000 (UTC) Message-ID: <41878012-e4db-4199-a3d5-ed2dc5badc0b@acm.org> Date: Tue, 5 May 2026 22:05:51 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] locking/rtmutex: Annotate API and implementation To: Sebastian Andrzej Siewior Cc: Peter Zijlstra , Marco Elver , linux-kernel@vger.kernel.org, Ingo Molnar , Will Deacon , Boqun Feng , Clark Williams , Steven Rostedt , Joel Granados , Alexei Starovoitov , Vlastimil Babka References: <20260505022649.870788-1-bvanassche@acm.org> <20260505161256.0NhG6_Hm@linutronix.de> Content-Language: en-US From: Bart Van Assche In-Reply-To: <20260505161256.0NhG6_Hm@linutronix.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 5/5/26 6:12 PM, Sebastian Andrzej Siewior wrote: > On 2026-05-05 04:26:44 [+0200], Bart Van Assche wrote: >> +context_lock_struct(rt_mutex); > > What does this do? Shouldn't this define the struct? This enables context locking support for struct rt_mutex. I placed context_lock_struct() on a line by itself because in my opinion that results in a header file that is easier to read compared to context_lock_struct(name) { ... }. >> --- a/kernel/locking/rtmutex_api.c >> +++ b/kernel/locking/rtmutex_api.c >> @@ -66,12 +67,14 @@ EXPORT_SYMBOL(rt_mutex_base_init); >> * @subclass: the lockdep subclass >> */ >> void __sched rt_mutex_lock_nested(struct rt_mutex *lock, unsigned int subclass) >> + __no_context_analysis /* ignoring the return value below is fine in this case */ >> { >> __rt_mutex_lock_common(lock, TASK_UNINTERRUPTIBLE, NULL, subclass); >> } >> EXPORT_SYMBOL_GPL(rt_mutex_lock_nested); >> >> void __sched _rt_mutex_lock_nest_lock(struct rt_mutex *lock, struct lockdep_map *nest_lock) >> + __no_context_analysis /* ignoring the return value below is fine in this case */ >> { >> __rt_mutex_lock_common(lock, TASK_UNINTERRUPTIBLE, nest_lock, 0); >> } > > *Why* is it okay? Because the void always acquire the lock and only the > conditional locking (which can be interrupted by signal/ timeout) return > an error if they failed to acquire the lock. Yes, that's correct. > Something like that would be nice for the comment. > > Not sure if "__no_context_analysis" is the right thing to do here. > __acquires(lock) __no_context_analysis > > might be better if just __acquires leads to trouble. There is an alternative that does not require __no_context_analysis: void __sched rt_mutex_lock_nested(struct rt_mutex *lock, unsigned int subclass) { int ret = __rt_mutex_lock_common(lock, TASK_UNINTERRUPTIBLE, NULL, subclass); BUG_ON(ret); } EXPORT_SYMBOL_GPL(rt_mutex_lock_nested); Please let me know which style you prefer. Thanks, Bart.