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 F2B00C3601B for ; Wed, 2 Apr 2025 21:35:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BDE2A280004; Wed, 2 Apr 2025 17:35:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B8C00280001; Wed, 2 Apr 2025 17:35:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A5409280004; Wed, 2 Apr 2025 17:35:41 -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 86527280001 for ; Wed, 2 Apr 2025 17:35:41 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id C14DBA9392 for ; Wed, 2 Apr 2025 21:35:41 +0000 (UTC) X-FDA: 83290410882.06.7337D2E Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) by imf11.hostedemail.com (Postfix) with ESMTP id D271A40004 for ; Wed, 2 Apr 2025 21:35:39 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=TewfCtCf; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf11.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.221.44 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=1743629739; 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=brdLyVda3kWWnBCMv/AMprmRoNH4Xu8Od2pJUYpkx9M=; b=FX10Q2OWxXEikLpSQyWFHB5CTM7DmQBvd6Uc/CxyLjEyHvH3wb6bQ5ocAgBcCv/v+kEnxi uodX7JcaQ5446JKHEHPJoObpMkv6f4bBYdz0PHfGIfRCwx1ppdPKv54APfB4zcjIvp/eNm pbGDWdvyeBmGcza237DbDy76g8dieeU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1743629739; a=rsa-sha256; cv=none; b=omrm689Xyuqin+IkrnEspBC8uYfTp61IHOuK3JyiXsJ9vJHldTf+AbYpHy65obipB37gfk uu3IL/gMmHR828BUYz7oTykIYvzo7TFi62BSOYgvWfY6SIKBzAjKB/mMw/rzM8UhChs2fa nLWuBpJwUlHvKKdJAkBjlhlOt+iP5XM= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=TewfCtCf; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf11.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.221.44 as permitted sender) smtp.mailfrom=alexei.starovoitov@gmail.com Received: by mail-wr1-f44.google.com with SMTP id ffacd0b85a97d-399737f4fa4so169501f8f.0 for ; Wed, 02 Apr 2025 14:35:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743629738; x=1744234538; 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=brdLyVda3kWWnBCMv/AMprmRoNH4Xu8Od2pJUYpkx9M=; b=TewfCtCf1RPdS6bwBfjIyEejOVixrhYhWp5JPSA70BCL8OttgTiNnlwfexRpBytrwW CdG1tmaDB+B8zz+UHhqSyCmXeMgopzTH+BzWbDprEU52CO5uLzaOCbmMNESFMCW3aC9T tdHWWLvZeJSD0QoXkquGLapws22lYAr8iPLL1LXueO5D+NWfwJTLBE8FqQLDUSWZeqZG d250/J1UbMP6hoAl8db49Wx90eHETURtlpoiRoYrvsMxt5Zhj6DR0wIdCwLFXv9PdmjX i+yXLwmRKNNoV2GgZSTxznXyBlfgYFXBL7kifrt2qYd+4C6hknYmxmwlPJ+EKhXtSM37 pzxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743629738; x=1744234538; 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=brdLyVda3kWWnBCMv/AMprmRoNH4Xu8Od2pJUYpkx9M=; b=v5ZcjRGQFxeh52WSClDMB8MGk5KJCNTzR+IK0zSoYF1L/TKNo93bQB6leRUxD8H906 PS/aofzUOwUuVuZEbY+LUb7x+jCP1NeFUya/uysG27ohc9edwFzn4/2rbYpHugRAFqFD HQftYtsBYDx4AruEUUB8+Da3g66RvjcZqr+la09v7266Lepm+tiPuuSrKgwBacg9R/Yj Yx97iwuJMhPSSAN2JVS53HO2D6AJhN9aQ7HFnJQDqyMMV48njKDDgQb/1Dv+XAAWGZ9h KlKNdHOS4VNMOZKiVvVIvzaYVBsRvskN1O7wRewSSBEVUtg3koMoXKp3H8nhKs4l/Ccs IdIw== X-Forwarded-Encrypted: i=1; AJvYcCVSRBh6l11UX+KZwnYwq8DJRw5bPIcP38b4tAR9M2T2r+WWXHITD+lEA/KhHzfelZt8GgKRr2Urvg==@kvack.org X-Gm-Message-State: AOJu0YxQbj/4CRfnOj3Eafxr8/blkEXz9DGHxQa7u5seBLCD6WOExfuq ZKZI3LZ1+Z+3lhSaCex3Coaek99xu60LD/8eqRV+EeINXrPDSfIhOkZckoQZSPFJDLCA7ax4l/+ Wx+Svjmox7ztIUfN8VOnfWJPx0gw= X-Gm-Gg: ASbGncsP+BBpn74PJxHevu+Zh7/lwamnwPzLFzOrnN9vk/SjXKxcrZh5kXWuEYgf989 jY0bD+n5LzpOXK2wYMIU+hCozDMTQelT/A0iyBqVRoyYAzpXWnpFN3qv4NSmi+wl/ZMACcKQAwH yTT1JjSfPf+85c20d/T1hNdI569sQIUYslKD5Zg4aahg== X-Google-Smtp-Source: AGHT+IEh9khh+XQxrrKzL3uCJcHHvKQ0W3+YC2DI86Fj1nx/H0McXWdoZl2jTZBX0khsEyydafgJXVelhh6XrjkK4I4= X-Received: by 2002:a05:6000:184e:b0:39c:12ce:6a0 with SMTP id ffacd0b85a97d-39c12ce0a88mr15273076f8f.21.1743629738008; Wed, 02 Apr 2025 14:35:38 -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> In-Reply-To: <62dd026d-1290-49cb-a411-897f4d5f6ca7@suse.cz> From: Alexei Starovoitov Date: Wed, 2 Apr 2025 14:35:26 -0700 X-Gm-Features: AQ5f1JreU4qniINicaLDIO4I4wqpWG0ejlHxOSbuNTXbXoAmlEP09YUm-6nmaPI 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: rspam07 X-Rspamd-Queue-Id: D271A40004 X-Stat-Signature: 71aob454ryr5i48jhhdcd6wpuhx1x96p X-Rspam-User: X-HE-Tag: 1743629739-151603 X-HE-Meta: U2FsdGVkX19OJeYqWNo6J+TPOV0Pwxd+EBHuWXydlyruSGQlXekX/nKBrTwbSSvnA1of3nzBGRk5ueUQ627Dm1KKR+NZOP/sCm9VgiTsD3DEWNaZU9JCBagjlQ4WlfDMVKf+vlQpTqqfER6azrm9Cuth4gS1Ps3eJ2UT7teMF9B0jt/REkoq4FZtrV22ktHL6IQeL/KX4oH7cRfi3FyqSAz7e9jfp7456fv5gmVjwspB4wvvfgjVZVPLT1HVW8sUOJ7BnP8WbKkHNrN77gbMKg6snZM/jiJ4/6HRe0LkXPuZH2DmiRBuBU7G/jmK1y5VCWM2YjxE3oJDWC66FDB30mq99tIEvt5JPnl77FP4oOQNZ3/rusQTK/5VPzF86xUZQssx1th6QdxO5RhHq5qQoF32L9rZ3hrj2mIZuW5Q93xf++wGWoWRavwXvHPEXFfQ23wExrw8m9xlFV1fIf9ZlC2P5GSDXcotZR+/jBopeZ8EvQXUcaFBjMhnkKxdKh09P333rwChOcKl7xU+ahYF6E0k5mjDt9lByR1TnTFBxdctbfUfXN3zYRugGEk/1zS4ydkhUnCwuuaB62V4Y54EvuAkLEk4fcjmz08VvSRQ/qjCEFg5h9kihZ+hJNZ9eBfRvgi+mRTRKP+Iz759dOmVcLZXduU5oQdu5eYfQIV7CkD4jlbNPYj8PJRNvW/9TRWjKp/oiiQF+Y8iW3HY9lDJpvXW+K9kXQWqyqQ1HJI6OzURti86J/wZKACEWoJNEjEgGyEDHDb7SCaHx3bvyje5+Lb4VUog93vFhX0Jz9D+MMe+4l1BUsWKg5eXkLJOoCDZ3UeEDcZUrpP0WSwcaRH0ZdKI5l4+cEip2GiMxDqzaETgwSh5jrnJAI7TcQfthy7VQLtnTf3TenLh3xp7qRWQ3oG8MHpON3Ens7cgMkW/dzIJQ+B25BE714Gr5UAUzcQlIbzLcJLykODHv4U5uSG nhoxOyn3 znXd9t6qoSVZ6nVWFPaAF+HKh1yix78M4Ky4KWmVAYadEqigSDMW/E1b/sIo4OkeeMldUxmxOeStp6XTCc1c8WKiySd1YXQj7UOZ6HpTqcrKZ6QAXUExhqIOsymM5hOH8SH+0xEdPbccm/OBPM2U4A//WV46HXUFLZwTxOQMZWmqTX1RP/otJ5ZYXdUwoXgroda4Td3r6c7iqrNcSt9xX2/XXKJSMyOFVG/G8oR006VTiuQk2dFAoM929t38/RA9K3pI2IEvc46mSemY59W6Xr53unfCbOUGsXAuyURnKQq79ECzrmjbILLiAs36Ivut1js6lUiefDMGGu4ENNCHJZdot7Smf0dP2fYZj1vGqRdwzz3uGwpiVSTnS9Do81Y5Yx4NSumlu9vAawhEQS5LmJwYv97HO9LwRKPRkZxOxcHtXZytmphyqRLOfMFoB/IdRllnd X-Bogosity: Ham, tests=bogofilter, spamicity=0.000035, 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 Wed, Apr 2, 2025 at 2:02=E2=80=AFAM Vlastimil Babka wro= te: > > On 4/2/25 09:30, Sebastian Andrzej Siewior wrote: > > On 2025-03-31 17:51:34 [-0700], Alexei Starovoitov wrote: > >> From: Alexei Starovoitov > >> > >> Partially revert commit 0aaddfb06882 ("locking/local_lock: Introduce l= ocaltry_lock_t"). > >> Remove localtry_*() helpers, since localtry_lock() name might > >> be misinterpreted as "try lock". > > > > So we back to what you suggested initially. I was more a fan of > > explicitly naming things but if this is misleading so be it. So > > > > Acked-by: Sebastian Andrzej Siewior > > > > While at it, could you look at the hunk below and check if it worth it? > > The struct duplication and hoping that the first part remains the same, > > is hoping. This still relies that the first part remains the same but= =E2=80=A6 > > I've updated your fixups to v2 > https://lore.kernel.org/all/20250401205245.70838-1-alexei.starovoitov@gma= il.com/ Sebastian, Vlastimil, Thanks for the fixups. Folded. > and to support runtime local_trylock_init(), and it's at the end of my e-= mail > > But I also thought we could go all the way with removing casting in > that way and stop relying on the same layout implicitly. > > So I rewrote this: > > #define __local_lock_acquire(lock) \ > do { \ > local_trylock_t *tl; \ > local_lock_t *l; \ > \ > _Generic((lock), \ > local_lock_t *: ({ \ > l =3D this_cpu_ptr(lock); = \ > }), \ > local_trylock_t *: ({ \ > tl =3D this_cpu_ptr(lock); = \ > l =3D &tl->llock; = \ > lockdep_assert(tl->acquired =3D=3D 0); = \ > WRITE_ONCE(tl->acquired, 1); \ > }), \ > default:(void)0); \ > local_lock_acquire(l); \ > } while (0) > > But I'm getting weird errors: > > ./include/linux/local_lock_internal.h:107:36: error: assignment to =E2=80= =98local_trylock_t *=E2=80=99 from incompatible pointer type =E2=80=98local= _lock_t *=E2=80=99 [-Wincompatible-pointer-types] > 107 | tl =3D this_cpu_ptr(lock); = \ > > coming from the guard expansions. I don't understand why it goes to the > _Generic() "branch" of local_trylock_t * with a local_lock_t *. 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. Your macro can be hacked with addition of: local_lock_t *l =3D NULL; ... l =3D (void *)this_cpu_ptr(lock); ... tl =3D (void *)this_cpu_ptr(lock); ... DEFINE_GUARD(local_lock, void __percpu*, then guard(local_lock)(&memcg_stock.stock_lock); will compile without warnings with both typeof(stock_lock) =3D local_lock_t and local_trylock_t, but the generated code will take default:(void)0) path and will pass NULL into local_lock_acquire(NULL); In other words guard(local_lock) can only support one specific type. It cannot be made polymorphic with _Generic() trick. This is an unfortunate tradeoff with this approach. Thankfully there are no users of it in the tree: git grep 'guard(local'|wc -l 0 so I think it's ok that guard(local_lock) can only be used with local_lock_= t.