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 02D23C36018 for ; Wed, 2 Apr 2025 20:56:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B443E280003; Wed, 2 Apr 2025 16:56:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id ACBA7280001; Wed, 2 Apr 2025 16:56:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 96DB4280003; Wed, 2 Apr 2025 16:56:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 77E26280001 for ; Wed, 2 Apr 2025 16:56:18 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id D4A58AB20E for ; Wed, 2 Apr 2025 20:56:18 +0000 (UTC) X-FDA: 83290311636.18.EF7A4B6 Received: from out-174.mta1.migadu.com (out-174.mta1.migadu.com [95.215.58.174]) by imf15.hostedemail.com (Postfix) with ESMTP id 208FCA000B for ; Wed, 2 Apr 2025 20:56:16 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=s77R92D0; spf=pass (imf15.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.174 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1743627377; 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=ENBk6Zps1y3iJcNgBI6UVcMLN7HDztYsknTvn4weW9I=; b=macdgM0FH3d3Jp4BSal0slfuWwuh54J5XbtnctyYn7gwSiyK4jKhpVXpfoUr6SggIglN7Z I72z/bcjj+rjT2MRlwAy49SYuu9YTk4qOx40a4FHecE50vAHKQSDTH8208/Jg+weQhotj2 oo9qclONS1wIoetQFfHknsZLX6ar2jc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1743627377; a=rsa-sha256; cv=none; b=c7sKiuq0tKCKtpDXMDqg0R33QXr7V1R3oSiVOqI2dZq2b2Ze5sixlt0dYhz5y7+34OQ90w rf7640hrTEj4F531Inp6SWVfZnZhDXmsjIpxYyU7gnJjzdHhh3MAn3jX9YguFlPH6uO/+N s4hIsTvocji9gyoZEW4ytRrzERrIPa4= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=s77R92D0; spf=pass (imf15.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.174 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Date: Wed, 2 Apr 2025 13:56:06 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1743627373; 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=ENBk6Zps1y3iJcNgBI6UVcMLN7HDztYsknTvn4weW9I=; b=s77R92D0wcOyKFh37BYitJugHAsVroC1aW2Rud2sNsta6FEInOiH7BlCpz5fbVHrJI+7Sk tvRwMrSkPMB9lZSmNXSX0rt9PhoEyGYDingWiM0o9KgOqHfoxtwa1ZjFtlN4wyTsFdRrJ6 EdaLC8bZvzXVYyL0LkHXyvXvY0PuO2s= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Alexei Starovoitov Cc: torvalds@linux-foundation.org, bpf@vger.kernel.org, daniel@iogearbox.net, andrii@kernel.org, martin.lau@kernel.org, akpm@linux-foundation.org, peterz@infradead.org, vbabka@suse.cz, bigeasy@linutronix.de, rostedt@goodmis.org, mhocko@suse.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] locking/local_lock, mm: Replace localtry_ helpers with local_trylock_t type Message-ID: References: <20250401205245.70838-1-alexei.starovoitov@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250401205245.70838-1-alexei.starovoitov@gmail.com> X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 208FCA000B X-Stat-Signature: bdhg3kyn59yg4nd74ctyj99ogy5xmjqw X-HE-Tag: 1743627376-975877 X-HE-Meta: U2FsdGVkX1+cl+m2c7rgxlyPuKE7S6qFhedrXsYhPCMiQl+fwgp11TgbV+qm1JWhQ+6d4S65TYoFjByAYMi9RBXXeCK6fI+IRNfOanh6VLvn5/w+7O5BORt9jITqXudX/F/YEVl+j/XUITnS8gQiVEXw3tgcx/by5waB62oD8w0b9KTjpoSSoj1OykgKfPRZpreljqmLphJTQZXeBGY+kmNWwSvGpJoeMyRiNUrrHXw6jcTmg44kgVcmiTdj66ruuwbs98Io6nkS0T68PDpEtw+82OLIa9oytVIP/I8f0YRdSoGEs3nfW5r63yT+DKH1lWphJpBe4KKNQpPSdyGKuz7MX7pMJKRMXYtYdmpCNJQ81OA7mU5Rag4CKRAld6+GJnDVVHVYOwtZgaM9218esSpLNpwbCHonz1fnhR/W2dCGaPfTsZ4OASiYoPU/iqXZYaEnd/8m6qvUje1xtm+zT0byAnYU02UPTWBYydA5tPjv8JSLDJvhUgs5bfs4A/XE/u/XqCWnZbPHIle6xDtC0A1Qp0rYFYVPIRZs6/Dz57XlDcXraxvVRJm1r+0OXMZXOPZTeRP0KQhZxslxNHH4dXfIAKZyvb6CHTBW+5zZooY61Boo4wp1CK1ZwE5hrIcTcNf0Ka83upavyr/eSVwzSYrSXNZbUW8oaCUwGb2ZDvCmh9cL///E+CceFQIm5GV48ssku6UXqTb0Db78dahRUvYvL/VNOyu4Y/K6JVRkhG7Cffx8Ia9dbrow4uCwrEKE72qYUfay/heRdBwGAhMvjsWJ3EhJZwO/1ksiqOa4uYWxC9x8jct2d0xG6+bZOE0CSJhIVMTH/GHGRGY9KBW3gwn9hPht9tNSxeaUztC//OjsbTJZRnaqNEIF/PxjsM4sqdS8J53huhe0Dzc5U4mF9zcU0T8T9kFEg3VG0wKKkomNGPSJXusidSEtP6WdcgbecPS6ryAaqOU6b4TtIDK aLAmsVQP Fwv0s1chHgd0A8Gp3IR5NASQZeYPt4uvSDEslpEp3RcQZwHzopYAskfwWga/8JxslzSWgT23vs4HTPzcjfjzoDC1SUgYigwICq/r80Suej9idgP//d+fGUiKrR6m4x62Fp6qPv8lqRh474pYnyT8BXOB/7hDLF/nSHXQ2K96i8D3BGrlU1wTS/KW1Em38UNPIJlTFlRG4Wq2UYPx6eFHFnnXUGDXYbdzxSTo0eM9n89kIA0qXjteLoMBdpt4slsjPe3jfvRRr1KXnO3YTGmolw3caW9/D8o/4lP1g4GoaPfyPWRW8+aeiUWlS8vF9CBpFtin6 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 Tue, Apr 01, 2025 at 01:52:45PM -0700, Alexei Starovoitov wrote: > From: Alexei Starovoitov > > Partially revert commit 0aaddfb06882 ("locking/local_lock: Introduce localtry_lock_t"). > Remove localtry_*() helpers, since localtry_lock() name might > be misinterpreted as "try lock". > > Introduce local_trylock[_irqsave]() helpers that only work > with newly introduced local_trylock_t type. > Note that attempt to use local_trylock[_irqsave]() with local_lock_t > will cause compilation failure. > > Usage and behavior in !PREEMPT_RT: > > local_lock_t lock; // sizeof(lock) == 0 > local_lock(&lock); // preempt disable > local_lock_irqsave(&lock, ...); // irq save > if (local_trylock_irqsave(&lock, ...)) // compilation error > > local_trylock_t lock; // sizeof(lock) == 4 Is there a reason for this 'acquired' to be int? Can it be uint8_t? No need to change anything here but I plan to change it later to compact as much as possible within one (or two) cachline for memcg stocks. > local_lock(&lock); // preempt disable, acquired = 1 > local_lock_irqsave(&lock, ...); // irq save, acquired = 1 > if (local_trylock(&lock)) // if (!acquired) preempt disable > if (local_trylock_irqsave(&lock, ...)) // if (!acquired) irq save For above two ", acquired = 1" as well. > > The existing local_lock_*() macros can be used either with > local_lock_t or local_trylock_t. > With local_trylock_t they set acquired = 1 while local_unlock_*() clears it. > > In !PREEMPT_RT local_lock_irqsave(local_lock_t *) disables interrupts > to protect critical section, but it doesn't prevent NMI, so the fully > reentrant code cannot use local_lock_irqsave(local_lock_t *) for > exclusive access. > > The local_lock_irqsave(local_trylock_t *) helper disables interrupts > and sets acquired=1, so local_trylock_irqsave(local_trylock_t *) from > NMI attempting to acquire the same lock will return false. > > In PREEMPT_RT local_lock_irqsave() maps to preemptible spin_lock(). > Map local_trylock_irqsave() to preemptible spin_trylock(). > When in hard IRQ or NMI return false right away, since > spin_trylock() is not safe due to explicit locking in the underneath > rt_spin_trylock() implementation. Removing this explicit locking and > attempting only "trylock" is undesired due to PI implications. > > The local_trylock() without _irqsave can be used to avoid the cost of > disabling/enabling interrupts by only disabling preemption, so > local_trylock() in an interrupt attempting to acquire the same > lock will return false. > > Note there is no need to use local_inc for acquired variable, > since it's a percpu variable with strict nesting scopes. > > Acked-by: Vlastimil Babka > Signed-off-by: Alexei Starovoitov Reviewed-by: Shakeel Butt