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 4C993C83F1A for ; Mon, 14 Jul 2025 15:54:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E41D76B009B; Mon, 14 Jul 2025 11:54:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E19DD6B00AC; Mon, 14 Jul 2025 11:54:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D2FDD6B00AE; Mon, 14 Jul 2025 11:54:09 -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 C15866B009B for ; Mon, 14 Jul 2025 11:54:09 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 6FBE6140213 for ; Mon, 14 Jul 2025 15:54:09 +0000 (UTC) X-FDA: 83663316618.07.3F8BD5D Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf07.hostedemail.com (Postfix) with ESMTP id 807C74000B for ; Mon, 14 Jul 2025 15:54:07 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=sNhrcmVO; dkim=pass header.d=linutronix.de header.s=2020e header.b=CenooRRU; dmarc=pass (policy=none) header.from=linutronix.de; spf=pass (imf07.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=1752508447; 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=xfxgbpirDG/4DqKWuHPV06tdlywV5pB/yCvyThpPMno=; b=U+nz/wMJf4aXEId7F0hTUSTe5DTnjfCYj0JqRVbq+vS5OIJJtJSmU5gBnRM3N1sy4IrxZd qxGfVVMFXU1nXfRz/jrd5z9RLemPKSg51INDQR6Q1KQbLes3C2K+h8+uGQVhIDlGBGHDUe +hg0v4IHyCIRuAZ9tu/MMBtoatiGOMg= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752508447; a=rsa-sha256; cv=none; b=Gv1cs1mK3oqKBUiV0LWx9tTB/hEB+hi/QX2cjT+7pPjvRt/Gy5CAHAfLtUB2qq3LW8r0lZ OHwAyUfTl9unNbIGQvN8XsSeGEPa3gd6QLg6x2M2DNcRyApQoUJqXgiz2XfYkHSk4XhNnX DRpmWHEGBxfpUlliumLvybM1QkcynmU= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=sNhrcmVO; dkim=pass header.d=linutronix.de header.s=2020e header.b=CenooRRU; dmarc=pass (policy=none) header.from=linutronix.de; spf=pass (imf07.hostedemail.com: domain of bigeasy@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=bigeasy@linutronix.de Date: Mon, 14 Jul 2025 17:54:03 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1752508445; 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=xfxgbpirDG/4DqKWuHPV06tdlywV5pB/yCvyThpPMno=; b=sNhrcmVOgz80smjkuLUzhvppTnv3o5XUYKyohdjm8U31CP154qpajIJkYe3omyHoSvsRsG NPRk/mJN4a4U7/VJ6HlXLaFSEiA/JgTp5Se9Yg3fpdVsr7yk05WBOT9buIkCEMuwCUck0E voDcUiDyDiNiZqtzH1nXxD4RpTSa6QqoYPEV0xLBwfYZxuNL8qekdb7Vicv8uZOQBBNLJy MtWMT7Aq9SjOkEeh3NEC+7yzEWr9f2uZYEHsPdwPvStDx3AVrxewXWKVFesbrgSNgU30K3 kGKma6mi9f+6ND4N5YdCDq6nAqYGvNLaNW53+Asg7c6g7VsoEunARwMBydU8CQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1752508445; 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=xfxgbpirDG/4DqKWuHPV06tdlywV5pB/yCvyThpPMno=; b=CenooRRUExsHoe0h+kQOvwmW9ugEXXe3M2iA4eq7a2wG5JN64grZv+mfWHdc60OMPwO9ET u5YNQOGlEuVmGADg== From: Sebastian Andrzej Siewior To: Vlastimil Babka Cc: Alexei Starovoitov , bpf , linux-mm , Harry Yoo , Shakeel Butt , Michal Hocko , Andrii Nakryiko , Kumar Kartikeya Dwivedi , Andrew Morton , Peter Zijlstra , Steven Rostedt , Johannes Weiner Subject: Re: [PATCH v2 3/6] locking/local_lock: Introduce local_lock_lockdep_start/end() Message-ID: <20250714155403.ThZUBUzH@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> <20250711151730.rz_TY1Qq@linutronix.de> <20250714110639.uOaKJEfL@linutronix.de> <12615023-1762-49fc-9c86-2e1d9f5997f3@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <12615023-1762-49fc-9c86-2e1d9f5997f3@suse.cz> X-Stat-Signature: w9w7mszh47fyc81rb17bfwadeoq54x7q X-Rspamd-Queue-Id: 807C74000B X-Rspamd-Server: rspam10 X-Rspam-User: X-HE-Tag: 1752508447-356423 X-HE-Meta: U2FsdGVkX1/h6U4JbwgrS6KuXbUOdzM3blwXq+SQaBiyYCk6SjEV7D7KagSjz0sI+6Bcxh00gmrJbjh6r40AQDe+nfCy6phAzoHWLKAPS3hMhWd/UgsMdJX2x3DDFEgZdF23vDm6OFhsevs/TTv9deTxcDO/ks1LxSY76QdPS6d7pzsXtb1VW4qN1jrSRTTjlP632BgIoIUgiViCedHlFsGmBbUXOBeJOYZynWnG+zunz7iKI78sthwrKM+UeRst5HONFffNE+x18VtIXDVUAGC6Mg4tR+YkWjB3B/0laCbuNr4tolmHlYU1RAMPY8ID5lwb6jR2BzcGO7U+RDpMwjyPkxOZ+h7KKi4LWhygB2vWlvErSkIIZSYE4fcd7roUM+EZ2BVlVlBF8z06yGODEYwcy3nk2zYPKlD81+AD2STvu8X08hWYVivZZffW8x8DM6hqTuUKtx+xvzaRAVMfUynu9QwyKwvzuA1dPpBJEyjmom8n7llVsSh7X+zXFqqdFppHuBjSs3wfPEJP7kesIm0rCxT3/rePdxchG0jiu6FAvXSQPIat4Q2ugkEh0PqqmsinZEzUKHboPoCACG5+ZYWpK9AX20klSVa4JzyJpxXvLIzKhLYcgWDfUWNdZEixWvb5ost/jChCT1txjYUT32WxovOrxejip9nqLzcGjMyJR+/GOZI1bfhoOUjAKwrW+4NbhQJGHXpMAErKHQHl4WFp89RAI4jbMVEvKcjTjEZgM/h3wHvIjN4lR89yA94r/WbNJysr2YdAYiHLk7bW9MhmVG5FMSMhoDneUJDk79CG9pRTqT9+mQPrI2UIOLWscM8vwGx2OhXgfbBlq8ozx6nwdWdBfq9mJM/LglVYqaRgbsrMrtAZaIvBB5XQvPwAKJ4wNYiirZ+xaCi705NWrSdSNSu5Ud6VD0nsMg/ZBTgP9sufz8Ov4Mb3Ln1vhnt6nJ6bRsTPJkRQZBPrVnC vDNSgB3E CiX1Rdujd8PREIiAaSkrAMby23ZMr02C3J56XEWYB7hmulA3w4VYrY24Z2Sgqy6L9iP+qAO2J2ng4DQv7S0oeQtjZzwSynV2QqCJNXAhQv41SkTOzzqwzY7iT9bjjIPmnM2hTKJS/0vNHfrQH8aLGYHASkVUMT7umV7JwOLjKQR3EUh4GOUr9hMGtelXrcL8ZEb9z3aPbfEF/OC37S+XBJTIn2cJsG16GEcJEDsijg5WOUtkVTi9Ouby3cEepMeRRo+T9EwtniTyDsHAyq4I51/Qj0oBq4YqRQRP0nmdAvyOg76+klIA3eu2RRw== 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-14 17:35:52 [+0200], Vlastimil Babka wrote: > If we go with this, then I think the better approach would be simply: > > if (unlikely(!local_trylock_irqsave(&s->cpu_slab->lock, *flags)) > local_lock_irqsave(&s->cpu_slab->lock, *flags); > > - no branches before the likely to succeed local_trylock_irqsave() > - the unlikely local_lock_irqsave() fallback exists to handle the PREEMPT_RT > case / provide lockdep checks in case of screwing up > - we don't really need to evaluate allow_spin or add BUG_ON() (which is > actively disallowed to add these days anyway) - if we screw up, either > lockdep will splat, or we deadlock Some people added BUG_ON() in cases were a warning would be more applicable and recovery would be still be possible. I don't see how to recover from this (unless you want return NULL) plus it should not happen. The only downside would that you don't evaluate the spinning part but this only matters on RT since !RT should always succeed. So why not. > Also I'm thinking on !PREEMPT_RT && !LOCKDEP we don't even need the fallback > local_lock_irqsave part? The trylock is supposed to always succeed, right? > Either we allow spinning and that means we're not under kmalloc_nolock() and > should not be interrupting the locked section (as before this series). Or > it's the opposite and then the earlier local_lock_is_locked() check should > have prevented us from going here. So I guess we could just trylock without > checking the return value - any screw up should blow up quickly even without > the BUG_ON(). As explained above, under normal circumstances the trylock will always succeed on !RT. But ignoring the return value here does not feel right and the API might get extended to warn if the return error is ignored. Sebastian