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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id C5220C3ABCB for ; Mon, 12 May 2025 15:23:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id ABF9D6B0167; Mon, 12 May 2025 11:23:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A45AE6B0168; Mon, 12 May 2025 11:23:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 90C826B0169; Mon, 12 May 2025 11:23:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 725006B0167 for ; Mon, 12 May 2025 11:23:37 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 63321B6DCA for ; Mon, 12 May 2025 15:23:38 +0000 (UTC) X-FDA: 83434625316.08.75C16F1 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf05.hostedemail.com (Postfix) with ESMTP id AA0CD100003 for ; Mon, 12 May 2025 15:23:36 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=tTUJ2Bsb; dkim=pass header.d=linutronix.de header.s=2020e header.b=axeR6NrI; spf=pass (imf05.hostedemail.com: domain of bigeasy@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=bigeasy@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1747063416; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=GzgD7yyKYi1dp3jkZ8Ijca5sabBJXlM7g63MwZ1HIyQ=; b=ExpwFjcCw/l1rZk9IO28cNXb4ZOGk85z1gQrS/ejl/XPlyN67TXjXXC5Z/RZn3AFyuCSSh EsDoy2TDTHWDCucAmm8/qLmOaK6Q2iPl2vlP5Oqk5XECMc7q/4X1MeOvkFhal5hdJ/xpYg EwJCmI0CdbESdZIaHEXHHyhJmOu+QIc= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=tTUJ2Bsb; dkim=pass header.d=linutronix.de header.s=2020e header.b=axeR6NrI; spf=pass (imf05.hostedemail.com: domain of bigeasy@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=bigeasy@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1747063416; a=rsa-sha256; cv=none; b=mVWV3xa9YJYqrZfrEKvbvFgnEQ1FwCRP3AWa0+nHRJXvEX5+vRGG+dUk3G7aKCoS37PfNj FDIq+ztw6w92BpQjP2iMebfA2/jWBX8UH0hp8ixdbn9x5+4hjwdbA1/7TEVKa53wm8bwmp 5TO3XBCb5Nr9WqGJ+axmVdvt/9FaSFo= Date: Mon, 12 May 2025 17:23:33 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1747063414; 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: in-reply-to:in-reply-to:references:references; bh=GzgD7yyKYi1dp3jkZ8Ijca5sabBJXlM7g63MwZ1HIyQ=; b=tTUJ2Bsbs1u1iudvU6Z4Q1XZw39SlWtOdTZlzb1577faCWjRpxx39QHIDjEzcAlD/tmlA3 jSB7ml1yjhDnJaSb68gLq4JfW+epTaQ36/C/ZhdgDgMaNurzMNcUYPz4+zudpv1RDEubeO cbzsC8vHzgdlMjwPlrEqN/NI6sfspjbEDExnGyG+kyEs/mPuZGIQUh7i9umGdY5upGGpdn ofOjlrnLIUQQXGpXov7nKtarHJZmvvGseFUPnEF8ShErFwJpxbHio4IvkdIp9QBME7+yDC n0n2UGVzXl4lHff2V/Y5qsr4WyfcK8rVIT0jF/+WhYM9vgNnp2+qsrq1cPuaQg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1747063414; 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: in-reply-to:in-reply-to:references:references; bh=GzgD7yyKYi1dp3jkZ8Ijca5sabBJXlM7g63MwZ1HIyQ=; b=axeR6NrI1MLAA8YAmlpCgbOIvkpmAeMOJ7a141r1yFqeV3BwUjxarmwdM5PiDItgmtUxOv q0LKLUbN4OcuscDw== From: Sebastian Andrzej Siewior To: Vlastimil Babka Cc: Alexei Starovoitov , bpf@vger.kernel.org, linux-mm@kvack.org, harry.yoo@oracle.com, shakeel.butt@linux.dev, mhocko@suse.com, andrii@kernel.org, memxor@gmail.com, akpm@linux-foundation.org, peterz@infradead.org, rostedt@goodmis.org, hannes@cmpxchg.org, willy@infradead.org Subject: Re: [PATCH 3/6] locking/local_lock: Introduce local_lock_is_locked(). Message-ID: <20250512152333.Di9sTun1@linutronix.de> References: <20250501032718.65476-1-alexei.starovoitov@gmail.com> <20250501032718.65476-4-alexei.starovoitov@gmail.com> <20250512145613.eD3DUEa8@linutronix.de> <1c9bbd31-10f1-41b6-b2b9-745ab4e9e2ad@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1c9bbd31-10f1-41b6-b2b9-745ab4e9e2ad@suse.cz> X-Rspamd-Server: rspam10 X-Stat-Signature: 3dyxuwcs5es867u3m81qkbycx9ihhdf5 X-Rspamd-Queue-Id: AA0CD100003 X-Rspam-User: X-HE-Tag: 1747063416-692608 X-HE-Meta: U2FsdGVkX1+fKfunQmkhANGq8A7KpUxNin8leubfRRDcWQJAH4YigBiF1ko4rrx9gqZRuLIdxesE+4c3xaa9V733MQ0dzdLBoUv7f+2ptcQWt9a85Ft5z/rcxLODuyFJNB4iBYFx23V9AnvHsAvPn0JYxXGygnkpKDH6EuQz4wEPGmj7GnRGfGY/PM146P3jXtgthr5pwMeFSRO+Z/jAgGgDbM8oYfl7Fe2H8ABH8PCyF5OkfTlzwMLKhIhDsWP4G+zXOlk192/5n2jkucaxDquMz6WeCoL3F1E8GpQvzWow67Du9FWjBiJL3Tc8piPUH/Ubvtc2gGtazjwc44j1MAAZs3sNUypup89HRP489CsWLraBVBXMScwgQa/tddfN/SwLbgtF6xzauPVs6lS0in0kUiAHu6+bYnC8qBsCDnIYi6ky7urkimZQnhKlwJ923gLXZepT2DYVzsESXyrOwNKjA2EsZzDFpKrx7wb6W8QEnq7vs7QQKtWoFIzQdtkMLTIemNtwGhrhrMmoZC0BMaasOt9ro0XcbGhkDoN3MQsh6bE0ykDQm/8ad2Tek9mKe+/1kZ0XNpf9o6n7F0WBC0zyej/40wJoSwnoxGk6SEq8vWkO8DQiLX0kJVKjWs1mH9TSRvUyAIErM1RyAKIGqcgN2YOts34KrsCzQaIazf46NLnPOy8s8ej+4xrYBfkEYMOngnknwO0YGVdGY2cgzEzu6TsaIj8mJk7sDZpsweUv+0sQH/nk00cZfRBcHoxl0wwhSztaQ1aavJcrU9BKY4hwzZaW99KftpPK537uNfDSKCwuQlciTuHJ7Ye1gqp/e5YNktLicAqNQLXebUY9oE2HVU5x61DTyfDmHTsbGUtaL3kcUFTtCbKKqvD1aabSW6FIQLka6OYBkSsbyygHlIupZ2ZzR3AyC0vlu/NNKrVrSU0GXF9UBIw58Kj0LngTROWSwtn4OsFDBNxAqW0 ZW9awooj AoaYlcRnQIZQrH3kdKF6qVpDg3xMENEJmsKHVqIxEsF3et4scF/n68figwadGHjs3rn9tU+y1pfX/PShLzbmKpp7dPJEABicwImwJbVshusH+k0qRgWPRXtUul2QB1MRkLlXBW+0XqddKDu+IFLhpLsb7zLmsm2HBnu1mTAqvwuZ3z/8cfEnhC28W6kQTBJpyMwTdj65++qpgpnQjsE9oVR0ZnUR7q2d6qYOp2ArKdHAs59RDH8kmG6NOtqDSTx+aedoHT9CQFn2SDC0aG+TOi4n1gJeFzAo7XZ0a38cqcTd0yjqnBhM79gThrLfC++R26vMNUk5iWgKoGuX3qudBYvZIad8oRzhHEbVckiGJecUwNJo= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 2025-05-12 17:01:55 [+0200], Vlastimil Babka wrote: > On 5/12/25 16:56, Sebastian Andrzej Siewior wrote: > > On 2025-04-30 20:27:15 [-0700], Alexei Starovoitov wrote: > >> --- a/include/linux/local_lock_internal.h > >> +++ b/include/linux/local_lock_internal.h > >> @@ -285,4 +288,9 @@ do { \ > >> __local_trylock(lock); \ > >> }) > >> > >> +/* migration must be disabled before calling __local_lock_is_locked */ > >> +#include "../../kernel/locking/rtmutex_common.h" > >> +#define __local_lock_is_locked(__lock) \ > >> + (rt_mutex_owner(&this_cpu_ptr(__lock)->lock) == current) > > > > So I've been looking if we really need rt_mutex_owner() or if > > rt_mutex_base_is_locked() could do the job. Judging from the slub-free > > case, the rt_mutex_base_is_locked() would be just fine. The alloc case > > on the other hand probably not so much. On the other hand since we don't > > accept allocations from hardirq or NMI the "caller == owner" case should > > never be observed. Unless buggy & debugging and this should then also be > > observed by lockdep. Right? > > AFAIU my same line of thought was debunked by Alexei here: > > https://lore.kernel.org/all/CAADnVQLO9YX2_0wEZshHbwXoJY2-wv3OgVGvN-hgf6mK0_ipxw@mail.gmail.com/ > > e.g. you could have the lock and then due to kprobe or tracing in the slab > allocator code re-enter it. Okay. So I assumed that re-entrace is not a thing here on PREEMPT_RT but thank you correcting. There is a difference if the lock is locked and you try a different one if it is possible just to avoid the contention. Otherwise fallback to the contention case if there is no other way. The other case is to avoid recursive locking. > > If there is another case where recursion can be observed and need to be > > addressed I would prefer to move the function (+define) to > > include/linux/rtmutex.h. instead of doing this "../../ include". > > > >> #endif /* CONFIG_PREEMPT_RT */ Sebastian