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 E9354C3600C for ; Thu, 3 Apr 2025 14:44:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 58D12280004; Thu, 3 Apr 2025 10:44:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 51433280001; Thu, 3 Apr 2025 10:44:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 38DC2280004; Thu, 3 Apr 2025 10:44:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 18E47280001 for ; Thu, 3 Apr 2025 10:44:22 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 419FBC09E7 for ; Thu, 3 Apr 2025 14:44:22 +0000 (UTC) X-FDA: 83293003164.10.47E458A Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com [209.85.128.53]) by imf13.hostedemail.com (Postfix) with ESMTP id 57A412000C for ; Thu, 3 Apr 2025 14:44:20 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=kWW8Kn4r; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf13.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.128.53 as permitted sender) smtp.mailfrom=alexei.starovoitov@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1743691460; a=rsa-sha256; cv=none; b=Q0VTOgRG6Kd4lE7glpRMmFEHxXbHEfG8Edhbu6v6DlbqcXCxm5gWkXhOz7f9LqsjHomlbY 1NUWTIl47r5oLRIRzqo/7nG4eA4/l6oaRfscSxS05x4fU7MYB6bJdRqIc870XfeH8fkS+E zg5dieUHUC/qhI4RRncasJci6jI1Pvo= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=kWW8Kn4r; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf13.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.128.53 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=1743691460; 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=nJcazkIEDozvWk+30oCrM412gCrQpqbZCL64NnE+en8=; b=67tTKuV7pAMwahp36tdf/8oKOe+5iTZnU3yreAF1guWIrODrBP9CiMdrtqIc6I7r1zatp8 do5+W1rQymtgucx4vqJK1b4Ur+2VtdEP5B935/YFYDEoHQOUod3rtAO5sR/IIEJ3a/xI79 jTok4VdA5S4H6oGrhD9JJSJP0vzZLgI= Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-43cf848528aso7503135e9.2 for ; Thu, 03 Apr 2025 07:44:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743691459; x=1744296259; 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=nJcazkIEDozvWk+30oCrM412gCrQpqbZCL64NnE+en8=; b=kWW8Kn4ric47WP93EcbLBOnTAru5Ir6McV6NSVaRY8BRH/buO135ydv/u3JrN7lWVV UDVtMjHyovSsOAOxF/5Hgm9LQHqtW48P3dlUNWmM/C96mGa4OSG5qQewLU1K1mSPnWdh MfOwC9r1+iPBpqF8PBUqflqY0OQCSZWUcxZecyXtCIILb5MNlluFdIFCjfS5JXQXyaXk FCnOAkWtycNShbFdXA6TB1A9EKsHPNauwrvK0SEMgfWPQq4wpjLI5orq2zqxLwmc47Q8 1WaaYZynDtxBolX+EpAKFPbJVYqV85cy/YvqHPf/RgjhV8fm1kcAKEt9Qo4YUvRe+d1n Idgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743691459; x=1744296259; 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=nJcazkIEDozvWk+30oCrM412gCrQpqbZCL64NnE+en8=; b=ttoQPOX/YZSwzkOhToxmyLqAYRsqW1s2lpi4A42NLAmyh7P2AwZ7YV0KGJI1iSB9wJ HrbwgGaaEIcyT/0mxRMr9t1UYJOZ9JOfWecy3YjMezpCEAacOG0r66kbhtFa45hc1hAx iX5tztIhx1qPO3TnND4gOCFI86j2LnrAb/uBoa7E8hD5UOile03J5jyllMCvvUNvdpgb OMD/Eegiai5w3JbKYmUoZYGMSiyCCakyfnTEjGfJ2LRSMB0/lzLDTxWOOJLIuFUkKmGx 5L8LAFw7hPStuLKDR3AUpGkZmrK4MQfQQ8LxZcgJjhUpiJ6zw2zyt2p6fDNiYrt1AQ/a BV8Q== X-Forwarded-Encrypted: i=1; AJvYcCWEYr8bQs5xmbcEj9ifeGsERGf9sDfJX52lYVvF0oalgqhDFDQkpklE05ZGKO92FTmBgeyaNtMEAg==@kvack.org X-Gm-Message-State: AOJu0YxpjHOE/nXc5si18QVLsDJlwEpQ4gt14aGCEWS2A4S9FcMNXmzb oySJAMXOFe262XlBBPJ0MzNGSsJef2Is73Rh0YNwokCzATIXI9qAm44IdGmJzxbQKUrLYvz2Hkh cylF5VJ1FTWMw+Rb2R5URstUeEJQ= X-Gm-Gg: ASbGncuHBdeAyv5S3Z9g/dmdcEAskPxnGYI/NsnzOJkgNO0nctyrSH6SsCUt3Lr0M/F Mx1J2a681YghEo43qQEyS11215VpvxEyYCNLofgI3X7JkLbBxzoBk3C5mOHQeUu1Z673e01srzt pOXEKkBcZmKS1KRpJjQQbGOtvXmdBBpfD/pw1mk6jbLw== X-Google-Smtp-Source: AGHT+IG1/M8yu7tmeJXQ7SghT6j3qDvLYNL6+WbZC5IEfpB9M3/7fb17gQW7XBGvptfcI4aM9iAfofQzu15/qT5TjjA= X-Received: by 2002:adf:9cc5:0:b0:39c:2c38:4599 with SMTP id ffacd0b85a97d-39c2c3845a1mr4322657f8f.48.1743691458671; Thu, 03 Apr 2025 07:44:18 -0700 (PDT) MIME-Version: 1.0 References: <20250401005134.14433-1-alexei.starovoitov@gmail.com> <20250402073032.rqsmPfJs@linutronix.de> <62dd026d-1290-49cb-a411-897f4d5f6ca7@suse.cz> <5feaf4c7-4970-4d9b-84a2-fcba2cbe0bc4@suse.cz> In-Reply-To: <5feaf4c7-4970-4d9b-84a2-fcba2cbe0bc4@suse.cz> From: Alexei Starovoitov Date: Thu, 3 Apr 2025 07:44:07 -0700 X-Gm-Features: ATxdqUG6OgL8s8t0wshh5CPMfg0m70fYQKXAvaU1p72IqliIQzRiFFQlOQq6XRQ Message-ID: Subject: Re: [PATCH] locking/local_lock, mm: Replace localtry_ helpers with local_trylock_t type To: Vlastimil Babka Cc: Sebastian Andrzej Siewior , Linus Torvalds , bpf , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Andrew Morton , Peter Zijlstra , Steven Rostedt , Shakeel Butt , Michal Hocko , linux-mm , LKML Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 57A412000C X-Stat-Signature: nt1ewnjoj5wpxw3mx44rzjzqr3gggbrr X-Rspam-User: X-HE-Tag: 1743691460-381092 X-HE-Meta: U2FsdGVkX1824yBbqgMG0ExpXW1KMbHNYNgMmeD1d4P7UB2FEn9Qo0mWQc7q+uN44IJEWlwcNLWw2hCbEwbANgGP1DqHHnJGouJ1W98C1i6Uf8iGZvpfqPiFuX1CK9G/hIsdtnwVAy6rUrfocO1mvt3rOUKvDMNdWhYgpcR9uwRYtjC0Hw9Tzzlg0fujseb8+ScopbmX9G6NF7ekw2NCw/wwhc3KnGAJAcIxwKj9vfA7S/hMP79koBQDUbyr3TWLt1zj6h75R/X4n8BzTbm5bbD+L5UwEgKDECRiXD3xtTqMg+veTTBWJhV105WlJUfUL5CKA7bW4m4bdcpf7+Fa7dVi1rSbYbXOw7U/BDTFwhUmL3CJRm+FfSO/1/8wgqjemFybW8o1V11VuOtyziu+zqSayuccFwQ95PDV0ijjAEuLLSvC5hk4hJ6UQ7Y02vBCaRFPWgtijfLsVbzSyIB4AzfM/nXvOIhjw6aKkZpT61sufcWMPIMPFD2LnzvaoPcnPbght/UyIkrcjYLfh3J8sI1i2o1Ph6xL961lMSjH245jVbtLURX4twXCk8pVLJIR4qYdnhJxvjC+wbiGHyLJEhmgghguVH4ZmIz/hDFHRVLYzelIujyFl1MkImC6NGUUQPH4ZUJikCO5+V5QDSwWEvZfqT2Pq0xtVhYfY4ZZtx/HfZNDuoD54lbVvbqvGwKg9W/yyE2/U05pGkvLOn8qkau3/qjEGayGbv4zlykBd4MS7oYCL1bnzr64dpc1nB9LX6yhq8mJ+iIX67QIuyp6k+cLkp7+XE826ocXA+GO4OeKKJ7U+pH61Q+fe8HVTzfFCsuyIMbZQbUo78jWI7pPqzRK9zldneObGA1T6B9GveXj7mCa+YeHkbFV6LEkLnHW3LUe8BDBrMjoLLyx3nj7UDTWVXS/OoBo7WO6PF3UQBMP6rxoOEke7WsEDzNDFrPKv3FAyQZ528ptBwxBjVO Q6068jLN pjMWvmW3yThVKSLc9jLzNEYiGwDHjPVhivt+6gbLKbfNiZbdm2Ou/hRX8qLPCRS5TwldtgdX51bGoN5SCKpyokzZSfdKVhgjlvryy/1ohaLEpKBCx9iXsqsNBj8TDwoWtoI0XohWYmEhdh2Ox3bIxpzQmJrI7zxu+0cEsmxJvrXncmYzmEJytD2YEm7kqN+X8TUInd+SlU2y6RrbruxKd2iFNIHDU4zEycqAvuCuIZGLleXMWvQVo9jka7/XK0fO2dg2nOYlGljxTJL65+feoA8YE1tW4b5jiANy4i6Q5zWL7c7FPfjlPRX7Qjx6sNLj2ndNhjvAR5AkNs2iZEdtGTxYMAJ4lbqfuYg/ySesTtSFLvkADJaAa0zn6BPnyrelfcb7Isa7qNdD2Xvo= 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 Thu, Apr 3, 2025 at 2:09=E2=80=AFAM Vlastimil Babka wro= te: > > On 4/2/25 23:35, Alexei Starovoitov wrote: > > On Wed, Apr 2, 2025 at 2:02=E2=80=AFAM Vlastimil Babka = wrote: > > > > This is because the macro specifies the type: > > DEFINE_GUARD(local_lock, local_lock_t __percpu*, > > > > and that type is used to define two static inline functions > > with that type, > > so by the time our __local_lock_acquire() macro is used > > it sees 'local_lock_t *' and not the actual type of memcg.stock_lock. > > Hm but I didn't even try to instantiate any guard. In fact the compilatio= n > didn't even error on compiling my slub.o but earlier in compiling > arch/x86/kernel/asm-offsets.c The compiler will error compiling a random first file in your build process that happens to include local_lock.h. In your case it was asm-offsets.c. Try make mm/ and it will be another file. It doesn't matter that nothing is using guard(local_lock). The static inline functions are there in that compilation unit and they have to go through the compiler front-end to be discarded as unused by the middle end later. > I think the problem is rather that the guard creates static inline functi= ons > and _Generic() only works via macros as you pointed out in the reply to A= ndrew? > > I guess it's solvable if we care in the future, but it means more code > duplication - move the _Generic() dispatch outside the whole implementati= on > to choose between two variants, have guards use use the specific variant > directly without _Generic()? Unlikely. _Generic() works only when the original expression is preserved all the way to _Generic() statement. > Or maybe there's a simpler way I'm just not familiar with both the guards > and _Generic() enough. There are options. Here is one: diff --git a/include/linux/local_lock.h b/include/linux/local_lock.h index 1a0bc35839e3..e053e187d99d 100644 --- a/include/linux/local_lock.h +++ b/include/linux/local_lock.h @@ -124,6 +124,9 @@ DEFINE_GUARD(local_lock, local_lock_t __percpu*, local_lock(_T), local_unlock(_T)) +DEFINE_GUARD(local_lock_for_trylock, local_trylock_t __percpu*, + local_lock(_T), + local_unlock(_T)) and it can be used as: guard(local_lock_for_trylock)(&lock) Naming is hard, of course. tbh I'm not a fan of guard()-s because I see it's being used in cases when open coded lock/unlock would be more readable. They're useful when there are plenty of cleanup code and goto-s, but not universally. In case of local_trylock() the guard is likely unusable. The pattern, so far, is something like: if (condition) local_trylock_...(&lock); else local_lock_...(&lock); so guard()-s don't fit.