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 3739CC83F1B for ; Fri, 11 Jul 2025 15:17:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7FE946B009C; Fri, 11 Jul 2025 11:17:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 788316B009F; Fri, 11 Jul 2025 11:17:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 64FB66B00A1; Fri, 11 Jul 2025 11:17:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 518446B009C for ; Fri, 11 Jul 2025 11:17:37 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id C7EBF1A0705 for ; Fri, 11 Jul 2025 15:17:36 +0000 (UTC) X-FDA: 83652338112.26.BD372B1 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf14.hostedemail.com (Postfix) with ESMTP id E280110000E for ; Fri, 11 Jul 2025 15:17:34 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=aXfg7je7; dkim=pass header.d=linutronix.de header.s=2020e header.b=QxeiEQWa; dmarc=pass (policy=none) header.from=linutronix.de; spf=pass (imf14.hostedemail.com: domain of bigeasy@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=bigeasy@linutronix.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1752247055; 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=pOCqH/qLVEN97c3uEHQuTllvWCzoEwEQ2Lqk+DAzhqI=; b=i4fNBIzue3tmWaa7QYq+X+xhkHV/fgQcADM4LiOlSIaFgu880SEjaf4CKZIBfcHs12bL2B oh7fJpGWs/ayi97CVelK1gx5jDM4jS/4bS+MBdMrOKvz6m03DzZi/UCKBPV4TfyaxZ0XJL AfACJXTQKY2c1R5nfMod4tMtoeINbGU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752247055; a=rsa-sha256; cv=none; b=PBcpJ3ZSl0wD/roaDkDJiQIilTfytEIrZgC4xkfxw/AcbC+akTNpZuqS9/gOPxT5rtTDUQ 1m2ZF3nhXos8ftqiocJd6y3WiAwpvEyJydCeDd7By/nGzJWTKu9RBYVl4qzC6uZrflBAZM hRWfisdSvbHS/TrdvzbiE3tfTHA0E28= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=aXfg7je7; dkim=pass header.d=linutronix.de header.s=2020e header.b=QxeiEQWa; dmarc=pass (policy=none) header.from=linutronix.de; spf=pass (imf14.hostedemail.com: domain of bigeasy@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=bigeasy@linutronix.de Date: Fri, 11 Jul 2025 17:17:30 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1752247052; 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=pOCqH/qLVEN97c3uEHQuTllvWCzoEwEQ2Lqk+DAzhqI=; b=aXfg7je7r4tU+Hbnm9yHX1TOsW12XtxZkqb3KygPeB460uaHaDSF6EiQgOHB0JOFJGNcLD aujJRxsZ/6lBZ2CkwCm2EIOnIVQcZXjlvikC/do11I8rSHPwl87MW3P0tiKfRoNciEMLfk bA6/EzQWMZzQHqcn//Aivdi3UmkKZxxDkeDrPjhYL3f64dQPFgy6eSdsy1PIeGTLMeeObp 8Rk+j2JhVjE7d8neAnyY2kbUhUfJv2Ky8Eu+KC1KZk8UHr5w4TOSwDVXH4KFSPGLM1L+o+ x8g9xzxL8A1fYpjPSjrIGFnjNgrkQ1SSQIFQoXWJRh2zcBdAiqFHPvwaIGLJeQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1752247052; 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=pOCqH/qLVEN97c3uEHQuTllvWCzoEwEQ2Lqk+DAzhqI=; b=QxeiEQWaq98hgkJbdo1XXIkkn1sv4ugt+f/J3/lNGZi1TcecI218GT5JSBidQfHL6K26rd UkYu85eOpnBrt7AA== 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 Subject: Re: [PATCH v2 3/6] locking/local_lock: Introduce local_lock_lockdep_start/end() Message-ID: <20250711151730.rz_TY1Qq@linutronix.de> References: <20250709015303.8107-1-alexei.starovoitov@gmail.com> <20250709015303.8107-4-alexei.starovoitov@gmail.com> <20250711075001.fnlMZfk6@linutronix.de> <1adbee35-6131-49de-835b-2c93aacfdd1e@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1adbee35-6131-49de-835b-2c93aacfdd1e@suse.cz> X-Rspamd-Queue-Id: E280110000E X-Stat-Signature: ewhexjqn9fwt89ath8nyqy7rq3b1cpxm X-Rspam-User: X-Rspamd-Server: rspam06 X-HE-Tag: 1752247054-800377 X-HE-Meta: U2FsdGVkX1+N53oxP30cEEefTcXlsNbelJHdA+1P7ah+oAWWieysdBA15f4KATZ33vVaXOWRphElaemTRhJjV4eNWbUNpcElSKkf+IS6qG+baAlXZoEGO8jXCcAZQMR03knyQQYKutXDGB93PVTw78KZAxmUNU5olZvyLgUh8G/FNi1dzispAaLKMqJ7lswci7EBCD0jgifojfTnAC7vLisGnoNOEJU2W2v09nVrVmEai5HX3FLra5sMleauENsTITMNBuI8w6JC8VAVSaxF31ME7CiPQMMq0DPuSEZO2iIQSi9PDtpVmYzF3uzTVrPpgrFIw6Odmd+mWvcfxDUMU6WDwHH/mMdTraUNLld9/sRjFS10VWS63p7WEMCj/LTR+PViqaurroImZ4bD0qVGnl45AVfBYtY69bPKFQ/JeZicJtR16wO9KkaSQKq2ro5aKbcjSnVVHDJZnjzNf7kqvxancXcGg7oY3Qudcb49UB+3+cf45BGpLaeU/LYfVzbqV6+yNmFRHcGoyI05U2wkKcs6nnJ0s7czuubNfFouULYCp0XI7vQHin6+DOJs69Ap2MVHDxjYWurmlKjXG59nem6KafMr8fCHB4KgVBBsScjEiMMlBA3H9YEg0GJcEUe+cf9dh9dJOc2rHgaxzLtUTsCXZ3OHrt66rACyyjTU2Ospqksfj0lB5bBOKkaIQYGv7dBIlmICBaG4w4XtPtkAgO/zGR9TgpZeMFgJ8SckBecOvpQTSdRbIZEe+D4h0eDASl0G70zl/NuwW7rOekXNLhQHO8Az/N8oDjeyDaNv7usXJMiUW4/tt5piN0SjTUgAYgN5JPrGJSOySqk54LSXncwxA9NwOA75nMc+ugAoB0cM428YwxBTsGU/YbaWjtEBSF1mpEFYiyToQ57EwfQgsSb6739CM/sFammLgCfgQ8kQNsVzi4t6lsboFzZJ7n8JVXzw5n0udLiAtFSnX5E JvjcsYqD xSLdQw+KTr5CBmMlfXmE/2irWxcuYcKNhOxn+IsuZYqcdI2sLkf507vF2dH9s84gSmSaG53ac8KZ/7nkes6pxyAoeMoa/D/7tBqpn2UrFWJyP5gSHvF9bPQRLyttghO89wzPo+QGT9lO2bt93ku6DXoAOSvmUKPP9cixIduTYFjce901PhIH5rknbtwNWoNhzDT58PSzVoNINzERye0MYs5QFMnc9ILp6r+J1TQ6+DOVXXoDQrd9GbMf+RoTbZvENB2V76o6oV27uADX/U7dk62FYADJ3FKzRJ2oDUKC3Okq4s0JOm34gvAddSuiKMXGQeUEdgkZMjLbZ0o4= 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-07-11 11:55:22 [+0200], Vlastimil Babka wrote: > On 7/11/25 09:50, Sebastian Andrzej Siewior wrote: > > On 2025-07-08 18:53:00 [-0700], Alexei Starovoitov wrote: > >> From: Alexei Starovoitov > >> > >> Introduce local_lock_lockdep_start/end() pair to teach lockdep > >> about a region of execution where per-cpu local_lock is not taken > >> and lockdep should consider such local_lock() as "trylock" to > >> avoid multiple false-positives: > >> - lockdep doesn't like when the same lock is taken in normal and > >> in NMI context > >> - lockdep cannot recognize that local_locks that protect kmalloc > >> buckets are different local_locks and not taken together > >> > >> This pair of lockdep aid is used by slab in the following way: > >> > >> if (local_lock_is_locked(&s->cpu_slab->lock)) > >> goto out; > >> local_lock_lockdep_start(&s->cpu_slab->lock); > >> p = ___slab_alloc(s, gfpflags, node, addr, c, orig_size); > >> local_lock_lockdep_end(&s->cpu_slab->lock); > >> > >> Where ___slab_alloc() is calling > >> local_lock_irqsave(&s->cpu_slab->lock, ...) many times, > >> and all of them will not deadlock since this lock is not taken. > > > > So you prefer this instead of using a trylock variant in ___slab_alloc() > > which would simply return in case the trylock fails? > > The code isn't always in a position to "simply return". On !RT I think we > can at least assume that if we succeeded once, it means we're not a irq/nmi > interrupting a locked context so we'll succeed the following attempts too. > On RT IIUC the lock might be taken by someone else, so a trylock might fail > (even if it should also mean we're in a context that can do a non-try lock). There is this parent check. If the parent check "allows" the allocation then on !RT the trylock should always succeed. So the return "empty handed" would be there but should not happen kind of thing. On RT this is different so local_lock_is_locked() will return false but the trylock might fail if the lock is acquired by another task. But then with this change we do trylock from lockdep's point of view while in reality we do the full locking including possible context switch. That is why I don't like the part where we trick lockdep. If we the parent check we could trylock for !RT and normal lock for RT what we actual do. If there is no parent check then we could do "normal lock" on both sides. Sebastian