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 9D9D8C3600C for ; Tue, 1 Apr 2025 00:58:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 60F36280002; Mon, 31 Mar 2025 20:58:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5C00B280001; Mon, 31 Mar 2025 20:58:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4AEBE280002; Mon, 31 Mar 2025 20:58:04 -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 2DA51280001 for ; Mon, 31 Mar 2025 20:58:04 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 78B1F1A09EE for ; Tue, 1 Apr 2025 00:58:05 +0000 (UTC) X-FDA: 83283663330.23.4E2B65A Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) by imf15.hostedemail.com (Postfix) with ESMTP id 8B1F7A0003 for ; Tue, 1 Apr 2025 00:58:03 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=THL3R5g2; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf15.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.221.42 as permitted sender) smtp.mailfrom=alexei.starovoitov@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1743469083; a=rsa-sha256; cv=none; b=aiQ6isJMjB+18r1PUrqXE18hVgufKMbQCyYQdnjDshlzDczhDAlk1/DZN1wYE0YC7HtUhr jc71oHyPei+B2GVnW+3f0HSbOJ755+ME4Iv41djCJEzaA1OD3eyy+j622WjICqar9ScZVh 3AZGdaAQb4k4wxyRUYRN2XOAMUxJZFk= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=THL3R5g2; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf15.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.221.42 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=1743469083; 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=x0iYDOSfDrBlNSH8I6mrWL8jmdYFnSU1gxLCAkOXxFc=; b=0A4gpEf6kC77iMoyczRcyDxxR2ApaoZc+mjylqV8MT+U3W8mEiwyAgTLsZNBEEyRu/37Mn nO4OYtp3sYKRqWJ8+PD3LmchXyicYPWHxduZ5xzT5rYIv/RhDyetD+XT8Nzol3R8Wp+xDz QidNLV0LfBd1UURM8rtEjwDI/5VREOg= Received: by mail-wr1-f42.google.com with SMTP id ffacd0b85a97d-3912fdddf8fso3737762f8f.1 for ; Mon, 31 Mar 2025 17:58:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743469082; x=1744073882; 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=x0iYDOSfDrBlNSH8I6mrWL8jmdYFnSU1gxLCAkOXxFc=; b=THL3R5g2VM1jFHyEoJRkBPJmsv9IE59pmnPCkhu5pXOgUysHRTXkuVny/bciqrlsUH jO3crZQFUwsOKwlmy+cHgECGvn1PGwOYIV+tDr3rEBscdnyea4tuJUzb+mpN/3f3MmVA 3nCovgZRcTJkhmea9qDqqj4TMhIMfnWL2/fTKsRBLMALmQ3hOzW37OZ7u7wxGxx+CDEk aFBIxheRwSDoMXAusZRfJ0nghUcnlO8qFRZdLsyK1h4kV1+OQumhjXA/9/9fnizsF40o H7nCC2bt10cebbQ7FV32YtA2ashqY6p+gG8wJxo5KuzA1+n6OHhwhgl82RYPVNtZL88R Fn6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743469082; x=1744073882; 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=x0iYDOSfDrBlNSH8I6mrWL8jmdYFnSU1gxLCAkOXxFc=; b=o41gTkyQnrHg+ghuMZTB/Oxe+RNHd+O/MmR4l3nzolT7czOMphCXC8iC1ttAp2pkev 0Ut7rt5Z90ca3P0F3n2xA2G6CQHibgRCKCn/nomKr4gXHjmg10Gk8KG7tCKoIMj6DJb9 f3mg2oS65BvXzhX3OAJXvjtuFDMcxIUiZnl7afz5XwCNOzVvPAQleYe0xflS87a9ulaM fyLd71QCPNAc6Sc6KTgtU4AUV51YgeVI7hsnXfYxMr+Puu3x9XVDIYZM7vSR0E4xRwM+ ZGCXsOZ+p3ZiJe8Xny6G3w2bJ1ciKKwP+oyJzq9U7e5Wmzb/S5rsR4DfmHcK8r7eTyAt bGvg== X-Forwarded-Encrypted: i=1; AJvYcCWysFk9lkG+DolNC+/09WQPHTU87wn9vfgEJjjKMxGS4WenWaCOW6maxLYSGUDAMQluZRR43l1Gkw==@kvack.org X-Gm-Message-State: AOJu0Yyl9R5JYVroONrIxbbQCU1t68ldNtMC45oGxntve/mez8B7b7P3 1H6Oeq++uAJDNPd3W+xaFt7Yo2SnL3+YG4DLKd8LUVU7/gfBtDiTcE91rW5/35AfqNiY70VVaeg i6KIPhnChw9UJaW/Z8m3dFwT9w4E= X-Gm-Gg: ASbGncu3dNbg/yck1YHCA8fgpoUq94yTzcHDx91E2AQr9rHvJe0EB6auwMlC7ADxWxj AKC5sQIS32zKZdH3PoU4iFSxhLTfLwlVTs4gMfjUOThW/LYFRmObKlakMM1vw2s7w9N/5lJyiOi 2eVEMWmJC5jHpsENMV+1fJRYA9eMks56tY6ghgBYcIVw== X-Google-Smtp-Source: AGHT+IFlk3G2zYxRJMwjk4o5Y4bO1F4MGPYwtlysnw//yIzwHhOdEHlNTaSPnjITPpwzmi5G3cRc8i5Cf5r7VJkeNko= X-Received: by 2002:a05:6000:420d:b0:39c:cc7:3c93 with SMTP id ffacd0b85a97d-39c11b9b835mr8415922f8f.18.1743469081837; Mon, 31 Mar 2025 17:58:01 -0700 (PDT) MIME-Version: 1.0 References: <20250327145159.99799-1-alexei.starovoitov@gmail.com> <20250331071409.ycI7q6Q2@linutronix.de> <39586553-6185-4b83-b18a-3716caf2f3cf@suse.cz> In-Reply-To: From: Alexei Starovoitov Date: Mon, 31 Mar 2025 17:57:50 -0700 X-Gm-Features: AQ5f1Jp-Ql02zVDgk6NuaN77iqrZ_5gNwycxoItRpXGJKC2W427iDqIaVxXr490 Message-ID: Subject: Re: [GIT PULL] Introduce try_alloc_pages for 6.15 To: Linus Torvalds Cc: Vlastimil Babka , Sebastian Sewior , bpf , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Andrew Morton , Peter Zijlstra , Steven Rostedt , Michal Hocko , Shakeel Butt , linux-mm , LKML Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 8B1F7A0003 X-Stat-Signature: 4g1yfw34jyxymc897p71d7u7nw9n4eqn X-Rspam-User: X-HE-Tag: 1743469083-532411 X-HE-Meta: U2FsdGVkX1+1sZXhefLKHtaTKUluNwGQwH694/BrQMuY9q5xRiMFnfnx3ffBHvuptBc/ZdMlfQ+3lFuYdH0x71MajlL9vocgF42yXywKOrxljhONxo05G6B1062OACFIRlLvvSICb8Xu0res+wZQ/vnCjWBR5lAYXdMvjEJjRcbwFGf9BdhAGRz67lww/QHvtwTEArTVoxSBoW0QEKhKYgHhNg05TVx7JH4aG7HmSuXmJRsork8RHkdiEI3pjiC1PkEU7l5yw1Ub5y2Bkmqa1ET12Py1zD4WbS5gYTQt3v3VmoKnHZYZ36nCCBKKm0hdMO1nx1zVLHSIu+eufThhi0rw9chA5tMfkNE5m+jMPRSL3n26G0XDTW56VeWUxhR7J8jTbTR1siMdAh9nQWxg88VfiqM9hoq5jiwWb+x1OXofu8V9sFt9bKRr+U4oLv5KNwemypHIH8deBRJddnA+jNM3TQlFVvBsxpUYKO8nfccxnWrKxWsyLdK81G6Jtvvnidy8ne4wFiRFAE04st7YAvcac/xz4VYagmbJcQ60pV85RfHKiPL/bWNwz5KvhsWxrCj5GfDGE7whIJBvZIb9jiA0YAP8G8XUrAe0KEguFXyttKhKrxU3GHOzht8M2Vw5usEJEh2It4IWNHQmpZSSBThAcemPUp9pHcur9y8A20MD6/XbfmR4n6770GARofW+dPaZVHqN9km7Wu2gJAxV4ftbXTbiOPz7r2M6eyp+RRCPNjGBUif4evvQft/hEtXlkDVptZEn5oCLK9zGxMchx5Bosq5QsCgPjRki4LEDbgnNfFvEq1FuuK2B+Ewsq+MRmuBtKPrWNyStaBvlGJ+DMfgkUKqzW03W5Vkzz5Au1g42nE16HtYtnZrq98lGEv+w0mHtAv3kRazyR45AbFnSGgQPMykzGgYG690cwfSI31kkts9CQ1/nJ8C+wpa1oiMUEXCsPBhptA52uJAMJFp Bhnhvkmb LY8+3N4nqExAW5DgaDVqzx8qEhltKJEnGqy9HZW3H6Eht/USvQBGbKoequKIxTECF9zAx0j/KzlKGLODzbpqrDBPHpAJpdn0irUUFeuKK3f4R4plnFX45tJseboapEhOY+kCIz5Fm3lzxrZjxu+2Tl4Yh76+UFECYi8Hj46iLJAC9+ZLCvzIl3EgJ3xP6VrcxV3sol+Vgf5eTap+pnFoHVVc5q6Auy5KDakojYxIt7Ln2WM2Mj8Op0VC1fYF+L4+qFd4Q8etWMHNVRIylgiNgsGgpyoI4VVx/Vno4tQfaGouj896g/lJT7EAxB+SwapvVfTgATzDGy+8ktY87/V+L4/ZPVL8q4QA/jw44IUKmqw0Bsf8YTbJ4EUdSApYVl0Ma+19a8zmwM3oT3cr5FbTegWrEkuumSrihMIV9pjtFY5IPNU2/4XswP1p8sx+Hg3dWpy16cIfg4gEqB7om1JEu/xIOQyqc2dIv4LuCsYXKxT2CIKdh9JO9LNyqmw== 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 Mon, Mar 31, 2025 at 8:35=E2=80=AFAM Linus Torvalds wrote: > > On Mon, 31 Mar 2025 at 02:59, Vlastimil Babka wrote: > > > > Yes I was going to point out that e.g. "nmisafe_local_lock_irqsave()" s= eems > > rather misleading to me as this operation is not a nmisafe one? > > Yeah, it's not a great name either, IO admit. > > > The following attempt [2] meant there would be only a new local_trylock= _t > > type, but the existing locking operations would remain the same, relyin= g on > > _Generic() parts inside them. > > Hmm. I actually like that approach. > > That avoids having the misleading operation naming. IOW, you'd not > have a "localtry" when it's not a trylock, and you'd not have > "nmisafe" when it's not an operation that is actually nmi-safe. > > The downside of _Generic() is that it's a bit subtle and can hide the > actual operation, but I think that in this situation that's the whole > point. > > So yes, I'd vote for the "let's just introduce the new type that has > the required 'acquired' field, and then use a _Generic() model to > automatically pick the right op". Here is the patch that goes back to that approach: https://lore.kernel.org/bpf/20250401005134.14433-1-alexei.starovoitov@gmail= .com/ btw the compiler error when local_lock_t (instead of local_trylock_t) is passed into local_trylock_irqsave() is imo quite readable: ../mm/memcontrol.c: In function =E2=80=98consume_stock=E2=80=99: ../include/linux/local_lock_internal.h:136:20: error: assignment to =E2=80=98local_trylock_t *=E2=80=99 from incompatible pointer type =E2=80= =98local_lock_t *=E2=80=99 [-Werror=3Dincompatible-pointer-types] 136 | tl =3D this_cpu_ptr(lock); \ | ^ ../include/linux/local_lock.h:76:9: note: in expansion of macro =E2=80=98__local_trylock_irqsave=E2=80=99 76 | __local_trylock_irqsave(lock, flags) | ^~~~~~~~~~~~~~~~~~~~~~~ ../mm/memcontrol.c:1790:19: note: in expansion of macro =E2=80=98local_tryl= ock_irqsave=E2=80=99 1790 | else if (!local_trylock_irqsave(&memcg_stock.stock_lock, fl= ags)) | ^~~~~~~~~~~~~~~~~~~~~