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 BCCFEC83F1A for ; Sat, 12 Jul 2025 02:19:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2030D6B00A3; Fri, 11 Jul 2025 22:19:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1B43B6B00C0; Fri, 11 Jul 2025 22:19:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0A2526B00C2; Fri, 11 Jul 2025 22:19:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id EC0BB6B00A3 for ; Fri, 11 Jul 2025 22:19:42 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id EE1A71D396E for ; Sat, 12 Jul 2025 02:19:41 +0000 (UTC) X-FDA: 83654006562.08.EE606B2 Received: from mail-wm1-f47.google.com (mail-wm1-f47.google.com [209.85.128.47]) by imf06.hostedemail.com (Postfix) with ESMTP id 141C9180003 for ; Sat, 12 Jul 2025 02:19:39 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=VWRVoMAR; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf06.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.128.47 as permitted sender) smtp.mailfrom=alexei.starovoitov@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752286780; a=rsa-sha256; cv=none; b=g7lxEVtsq4ypzEf2JSesNHQaEbx5klMY2+c4CpLmRzUvpKSjeR/yYz20NB2hIBAeVk/jrT eISL3QvrTxhV3nfY93F7o03JEhRgFrYfWKufJ89InqEu5qPF/oO0ZQ++9mz7AwcYCIWk4z QrEa63999Nuj4+npG+h/PW8Yd9HxSpo= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=VWRVoMAR; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf06.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.128.47 as permitted sender) smtp.mailfrom=alexei.starovoitov@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1752286780; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Uiz+Wjac2zk6sV3PXzlRZmsGBC8DDXKjUcG6BLxmh7c=; b=Loqv9WoYQQ+bjmQu3+pxsLTmlnHVUWYIB9aH08W/mL4U2yCO8s8mRaKZ93LjKGaWvaA+TJ qkuHyowokosNzZkCTjmtQL+VMEX5n32ZmFRS7Tx93aX10spfpApEq4AnN04y27ZiPQqGH3 9Ook9D9uCfHpgtO8GPqOjHsUUj3Ib+g= Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-451dbe494d6so26435755e9.1 for ; Fri, 11 Jul 2025 19:19:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1752286778; x=1752891578; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Uiz+Wjac2zk6sV3PXzlRZmsGBC8DDXKjUcG6BLxmh7c=; b=VWRVoMAR2Qhe22hRXHL798FnU3V0zHZUQergoWdug9+AKVdHwiFrIvAspr1gkh3OVL cLyiIYx6q28KUYx9J6qqMcApDEHCf9rf4IDZeU3ywGBo1rHvPXHLDu8N34H1U2LpED54 W89BqQiOAlKV6GE2Qyow3D5nIqoVCinEtOjptptflZI9/BG1+bB40Di1uUcrQtZ8lgIS +GwSeq9kE8wOkK9HWfzgXA2TvGnUQAEXyxxUpq7kUm1UDNuXeOOGDl/53LPHVuFCcHO8 JhUtE0P5QG+UOl4iL+HDm1MdPxzlkgXkePDoDw31hJ27hl+IQHrnzWEH4DGNgGJsyjWi 0C6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752286778; x=1752891578; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Uiz+Wjac2zk6sV3PXzlRZmsGBC8DDXKjUcG6BLxmh7c=; b=srW0otmMnGfY5452JwDi2O8m7GSiv1Y7iMz8M+120ay4MG0xZK7IKzFoASsVFwMJ2N NH3EwRiuNm+EYhsWJNg9jRU6InOOrEvxhkLJutjbPL8Gv9h7M0JYW+Z7pt5EoaU4Msub s1dC54gDifPCZEH1IxTqlCnTpSYSWASlBarbrPzssCciwMFXdKNnJZPsmW/fIbNLrMc6 t39rzWaBs29SU9tRq3pATpp2tbB7MF731juM7AQD/7deWTBuowQKJLsTcu9UrjJ+hGSh nL4ugbLd5dVT7F5rZkb8odJZWjxa5cx4rY13yYLgx04frGd8c1/ggVNfbyfyrI6O8ggd QQFQ== X-Forwarded-Encrypted: i=1; AJvYcCWzxj0ewXFx9VBWP/tnDsg0v90HLcdl15nJhezFvsHH46DF98/Gpq/rLm5/PbU9Bpu9TMISWoEnlg==@kvack.org X-Gm-Message-State: AOJu0YyL2uQ3CRPeDkpe5BqGfggmqsnA4bLC9lcw+aGzokaKgqw26DZ5 BxTwhWrPi206pl1rq5j8fqA5sLIwrPwo7cA1+DH6J8zdJSquV2D1CSkNXhAvXiuGNMbIui+b7g5 aQSWoSw8PbYq5laaV4DC7djFTTRRjbyY= X-Gm-Gg: ASbGnctgPQ51aqL9LKpivTz33ORPBt6BUNTst8mcQkKEHO5z6ysxVD3H3dIFPYwzIZ5 hl0V94vHbptGRQVEL1FWAaAMOB4fk6xsYXTs5FMhgo7LSwMfs/5quwZQRjEDio0ftdnc0dV/Ek+ x0G/R2lQFPPAKtHROCGKA5gb7IJ3MSCemyO7VVLWxOepzwjvBmfbCLDU6XR+oPK+vMzcUAlszlU BzvNBUPqiyWJKlV6Ltw7RlBC7KaqkU7RCap X-Google-Smtp-Source: AGHT+IHK1A5wZKfGjQ31k8QtcClWeGZN6HXl0c3a+iM/D3LUG/K8rSyF8bRBt6IW0sDLde25WiRJfSHIr5Not4VEewY= X-Received: by 2002:a05:6000:22c1:b0:3a4:e6e6:a026 with SMTP id ffacd0b85a97d-3b5f2e1b3d4mr4431436f8f.28.1752286777971; Fri, 11 Jul 2025 19:19:37 -0700 (PDT) MIME-Version: 1.0 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> <20250711151730.rz_TY1Qq@linutronix.de> In-Reply-To: <20250711151730.rz_TY1Qq@linutronix.de> From: Alexei Starovoitov Date: Fri, 11 Jul 2025 19:19:26 -0700 X-Gm-Features: Ac12FXyW2V7duVfO2RxQqGtBjl5d5azhqldja6Jh7VAngRU8ULFXtL5-v2QSK9I Message-ID: Subject: Re: [PATCH v2 3/6] locking/local_lock: Introduce local_lock_lockdep_start/end() To: Sebastian Andrzej Siewior Cc: Vlastimil Babka , bpf , linux-mm , Harry Yoo , Shakeel Butt , Michal Hocko , Andrii Nakryiko , Kumar Kartikeya Dwivedi , Andrew Morton , Peter Zijlstra , Steven Rostedt , Johannes Weiner Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 141C9180003 X-Stat-Signature: nopboznf9xxsxooptprmooecujfsj168 X-HE-Tag: 1752286779-409524 X-HE-Meta: U2FsdGVkX18SYtnLnbzyyTGHK7KUKuc4vGZkrHSqMlW3+wM8bhnSW1isYJcI4bNk0QHRv9xG+/4bSYxv1+8wkcKMjxfbZDjwDILwkYfLJBFE/M1GyM5bFBpdIfSyYLBX23mPbWUiTPRDd4CQ+iA9L/4i7sH6nBD7MJVvyWDDataBHecW3sgxcCyes3EWoz0Cyc/tAz7+RLeB+qtoftb3wJt4C/04rXA4SB380KwRCpYLLuY2MzOS8CPfzc3v3/S5VbQm5zpS1qPI/AZUv4VlV9mAo9wwmXmNoJ/twokSRxt/p6982i+SSvejSfqO7i7qZG92dk8tX39P8Q7fO73isEqU9KZqYUxoZR4Wxgk6CGV3uVeeVydvEh4t/9CBXaiHXl0528VfsB6cSfnxPOodv/rMKpQWeSjhTRlus8zg54/xOt1owzejK05uiJRGNYftPc75OUp/+Xt9H3+kq/tR9Q0cxQpPzoGhYb9lRUdgaZ/+d+wIxNKxxDEftBOFZpt0A15ANGc8mBpOdT66gjrmkpND9T2G7wml2uR1dWhk9HeoDr9OzKdPtpDl/0GZKhqVREFb7KO/xwqnka1Yt29OUqmk8jFzM9ymjuqKNuTku8Omg+fIch7jOK7Dtlam7Z4p19xBBfiUCFGEORfFPST2YJGQul/1dfoZZNrpgM0Sc0+9ivB/8O4qQ4R2ow7en0V2HMR001t7w7KvED8zygjDRDelqMqWPXWFOnWpfb6agPOJ8GTgWoZoRf3rVLrdiGBKrvybME59aw4LOAo44SVFJ38RXoFG6i6zp2WWArPW4qtbu2VNfUqZynN+GyDbFQWqJ+hx2N697ZPI4x3F1MOROPTjEuNjBs0IBMHmflv1Fxq1kOfCNbv8JOY67F4YWS4Dgpsdj5RxTjrCWOwuYODuVOSh6GOYis1aWYJHlWz/1v55fB8xGKE3kiC/P9QQfdmeHIeETEi3/6V6vbMvcYs Gviv0+rL 3mdAKDY4cTu2BwZhoC11aban+X2VA7qnAiUqq0hef0uqocVtoW1X21j6QeHhwXuI4ZekCjwrG0QsR5rnAidAQD97ulNVkNogkNjt4Ymg9nP0fBrazbB9e+LlccKMa/J/XtTkLyPEore4Fl9CNc/C0zqW6bYmmCLNjKYysFO4YnOTQ1hhN7JMLR5frBh2RYoBNnGlML7vV1lEmeTM6DiofEIyZUJBjQ7OR2pJmis96lw+I0QwmPkd1go+ky4WDFZBxfP/FbxDWt8Hz6l3dGuWjCjIhkWg3VeDRVzBltQPomCnz/uZ7pxZxoz07Y8By7EQr45JEBmWP/koIdp2jyKrFA4rVjnQTCObsAtwsvFEinRW1LNzVKrPkbJkHhVsTY6SrbxVJZM3pBm5FsoIZpyURWtIivxj3zCoISCA8qNxA4nJRoqMFE51P6xRVqc3Rz9jb+/31s8HuT3fLlTE= 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 Fri, Jul 11, 2025 at 8:17=E2=80=AFAM Sebastian Andrzej Siewior wrote: > > 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 =3D ___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_allo= c() > > > 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 t= oo. > > 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 l= ock). > > 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. So you're proposing to replace four local_lock_irqsave() in ___slab_alloc() with if (!local_trylock_irqsave()) return NULL; and a nasty comment that it shouldn't happen because we did local_lock_is_locked() in the caller? But for RT it will pessimize kmalloc_nolock() chances. More below: > 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. Exactly and that's what we need to avoid. Sleeping in rt_spin_lock() is fine here, since the current task doesn't hold this per-cpu local_lock. But there is no such lockdep concept. Hence the need for local_lock_lockdep_start() which is purely lockdep-aid and doesn't affect locking logic and checks. > 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. correct. In RT it's better to have a full rt_spin_lock. > That is why I don't like the part where we trick lockdep. yes. we do trick lockdep. I don't see an alternative. lockdep doesn't understand this part either: "inconsistent {INITIAL USE} -> {IN-NMI} usage" So it has to be tricked regardless. > If we the parent check we could trylock for !RT and normal lock for RT > what we actual do. How would you do a normal rt_spin_lock() ? lockdep will yell for two reasons in the commit log of this patch. > If there is no parent check then we could do "normal lock" on both > sides. How would ___slab_alloc() know whether there was a parent check or not? imo keeping local_lock_irqsave() as-is is cleaner, since if there is no parent check lockdep will rightfully complain. One can argue that local_lock_is_locked() and local_lock_lockdep_start() should be paired together and that's what I had in v1, but they're really different things. local_lock_is_locked() is true run-time check regardless of lockdep and the other is lockdep specific band-aid. Keeping them next to each other in __slab_alloc() looks cleaner. Maybe a bigger comment is necessary.