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 3D409C0218D for ; Wed, 29 Jan 2025 08:17:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 99F6728003A; Wed, 29 Jan 2025 03:17:34 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 92859280038; Wed, 29 Jan 2025 03:17:34 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7A19E28003A; Wed, 29 Jan 2025 03:17:34 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 596AE280038 for ; Wed, 29 Jan 2025 03:17:34 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id CA3A412070F for ; Wed, 29 Jan 2025 08:17:33 +0000 (UTC) X-FDA: 83059785186.23.2F15101 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf20.hostedemail.com (Postfix) with ESMTP id 05CD81C0008 for ; Wed, 29 Jan 2025 08:17:30 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=f7VyE5jl; dkim=pass header.d=linutronix.de header.s=2020e header.b=MimCJlxB; spf=pass (imf20.hostedemail.com: domain of bigeasy@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=bigeasy@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738138651; 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=ubwupqMU7Aau/E7dbQGwTNwl8txzA7eXEiahExGy9ko=; b=uA1AnNQxvgFrRJD0hOs1/TTv1/jkZcA/KlTryNctHBILIb8+0dM7fvG+Q5l7csnTUgdXX3 6G0poUQBtOd5vi7mbiOMLG8AQTSF6p17hGYZviAFhrZXphJ63E/8iBtjDn6GsCN1H4jeUc 5ridHIautC890M515Fn9U3wJPQ4osVI= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=f7VyE5jl; dkim=pass header.d=linutronix.de header.s=2020e header.b=MimCJlxB; spf=pass (imf20.hostedemail.com: domain of bigeasy@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=bigeasy@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738138651; a=rsa-sha256; cv=none; b=pSlyisc+I6kVRkMt8q7uWlORztQtX1GIOm3BPzAmjgtvk5UjtnqVRlSaBkBgBbAaIbvkir H8NUHDtQ7Sp7k24oCpsufi3pssHVnBGMU+WZcDvrAUW0vcDJQEYYNs68UKYorydwixAeyV aB7wL33HiZKZHdCrh6bB1l2n1SA/Kk4= Date: Wed, 29 Jan 2025 09:17:26 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1738138647; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ubwupqMU7Aau/E7dbQGwTNwl8txzA7eXEiahExGy9ko=; b=f7VyE5jlkeMJYQW+38wMyNw1JoDJCSfqaIFhvRQi2Wn5ny//hE7VhEK8cY2IDTyffME3WE UNiGP89/Y9a3QrrvG7T6Mb6goiuIUSKYaDYZNEJ0HL/M7BuMH93OrdL4p6HbVPH+d7Ndly XTOx3GI8Px/TrCRGscaDHCZ1zElTWB84STX4fp1Bkzs++MKe7n1v0nFOHmfk0tXTy0KnpT qOWx5jadgIRjW9Zu4UJ7VOAn3J21ep1MJwEW6iRB0oBZRApbqwpxs4+FiB+p3d0RyLPPRS bryEU1K1kHmC9H04T3qLzupUmDefcu/tXuKMrrFJ/y6W2CYU8v+jgWqjhMxCEA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1738138647; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ubwupqMU7Aau/E7dbQGwTNwl8txzA7eXEiahExGy9ko=; b=MimCJlxB6a/6gptRkHvVOAV5C8ZGLogrWeMJaZH0qKU5uRqcyXwlgDS0y3btGfhC2wRgF4 BR5LfQoqCWVlhABA== From: Sebastian Andrzej Siewior To: Alexei Starovoitov , Peter Zijlstra Cc: bpf , Andrii Nakryiko , Kumar Kartikeya Dwivedi , Andrew Morton , Vlastimil Babka , Steven Rostedt , Hou Tao , Johannes Weiner , Shakeel Butt , Michal Hocko , Matthew Wilcox , Thomas Gleixner , Jann Horn , Tejun Heo , linux-mm , Kernel Team Subject: Re: [PATCH bpf-next v6 3/6] locking/local_lock: Introduce local_trylock_t and local_trylock_irqsave() Message-ID: <20250129081726.vGHs_2kD@linutronix.de> References: <20250124035655.78899-1-alexei.starovoitov@gmail.com> <20250124035655.78899-4-alexei.starovoitov@gmail.com> <20250128172137.bLPGqHth@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 05CD81C0008 X-Stat-Signature: ixz3ba8xj17kzn9joethkhx8fm8uc86z X-HE-Tag: 1738138650-206515 X-HE-Meta: U2FsdGVkX19gPpyAZrmZ3I3hmELPfG8e3Xk0RFoWPlqmbIaIUPjRZq7mmlK1IHjoVagVs34VTEswr52Iii8opX4vcLHDvGskM3Tptrzwq4SEJvbzPKte3HtuKrXDsBHOG9IPvujwusYf3g/u9s6MNb4QHiE2ARdu//sjavPnBmVMYPZN4hjXMW66j8u2Nw5SFc6j/4Q1azUHmZxFSjQ8i0fLx6hNC1OdIP/Kpi6q+iIvhSzG1h2/iA49eYW64IQ5xKPqoWxKzuwY2zagOXXVkJQfmUHzaVVNEUDW9LLDsbecXy5sYhuGSkrQ/dodEqCBORHlEPpXmx7WzHLVaI2pvALOdgH7lUzdRCI9M/Dfhuo7ACbwSJAEvGEBQWfBjTJwb/3T5WHyXR8Y3CWv0f7AdB4PzApiPcWUgPANx7f/+IAyiz9Y/jgmPLoyuMAjTyGtCnF3yiFSv6OooT3nl6l0wytV9lORD1tNyjTO6UUi5h/s7eTCWPAo866uvxs07nLTbzV4XerzwB9tLhbp+PGyCXnz8wpB2Tl4upxCbBK9yfMa/H3iQSSgk2kU8y2wAuT8mIkTE1HQ/xhcJvBBhFCyLQ2H0y991Un9YCWmmYU5PkC1ZjiwI4A8umVmkKuUOTDt9t/4T2H5Kepc7WojYAS6vZN6h2z0DQLwz+/9qD3ctLxHWA2HTINS2emxmDQoqr3RoCEcdIk2cbU5sFeNnU6VCz7sFNIzb5pe+aIp3sknzik2b7mTEUxRpMo12eLZHv9VLQDzg4SdMdBVGD8Tw+VbTENFv5WpwOncJZRPmEk0siB122xOiv0AFzTt3vn61Eu76g5Pa5PIHu2BdUqSKnE5ZOsIW+jwrm4dRg9zrD0Sg8UJvaUjYP69qyB5pp7NxX2yZwH6Hf2Kk9h3jSpm9jJqStx8FFnNrDq9h9b1KuWDXwhS1wY8MGcSFYdnrsQW2wrJErym4W4vX7AqDnPwaGk qF/wvYqa DUW2PSEMO9O6Qc78xOSsWh+hnSlmnZLaG8M7Abl0KYnDaIHkotXw7es/Vrb5zX7/qLvUNgCI56XRe0y3zgkDaAVLZ/1UcX2vwQ+bxiQ/Yt7d7UA8w5oLhWzM+lOLf2zrvinYvsYCgpdIE2M97p5MiQit21tUz0DiUlnPHpWu33HBbVmdNrQvnTUVfqyVOvz/4n3rmplB7n9w16MKKRV/eqPtTpw4VlyYou95QkcdgDeIXfCV8mZ1iIkEdQFUtHJP4bEjxHo9wHSUQEuqS7sVrj9qqCaBow+oEvnDLIFOuQGIAzrOqtt4MLY6VzA== 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: PeterZ, may I summon you. On 2025-01-28 10:50:33 [-0800], Alexei Starovoitov wrote: > On Tue, Jan 28, 2025 at 9:21=E2=80=AFAM Sebastian Andrzej Siewior > wrote: > > > > On 2025-01-23 19:56:52 [-0800], Alexei Starovoitov wrote: > > > Usage: > > > > > > local_lock_t lock; // sizeof(lock) =3D=3D 0 in !RT > > > local_lock_irqsave(&lock, ...); // irqsave as before > > > if (local_trylock_irqsave(&lock, ...)) // compilation error > > > > > > local_trylock_t lock; // sizeof(lock) =3D=3D 4 in !RT > > > local_lock_irqsave(&lock, ...); // irqsave and active =3D 1 > > > if (local_trylock_irqsave(&lock, ...)) // if (!active) irqsave > > > > so I've been looking at this for a while and I don't like the part where > > the type is hidden away. It is then casted back. So I tried something > > with _Generics but then the existing guard implementation complained. > > Then I asked myself why do we want to hide much of the implementation > > and not make it obvious. >=20 > Well, the idea of hiding extra field with _Generic is to avoid > the churn: >=20 > git grep -E 'local_.*lock_irq'|wc -l > 42 This could be also hidden with a macro defining the general body and having a place holder for "lock primitive". > I think the api is clean enough and _Generic part is not exposed > to users. > Misuse or accidental usage is not possible either. > See the point: > if (local_trylock_irqsave(&lock, ...)) // compilation error >=20 > So imo it's a better tradeoff. >=20 > > is this anywhere near possible to accept? >=20 > Other than churn it's fine. > I can go with it if you insist, > but casting and _Generic() I think is cleaner. > Certainly a bit unusual pattern. > Could you sleep on it? The cast there is somehow=E2=80=A6 We could have BUILD_BUG_ON() to ensure a stable the layout of the structs=E2=80=A6 However all this is not my call. PeterZ, do you have any preferences or an outline what you would like to see here? > I can do s/local_trylock_t/localtry_lock_t/. > That part is trivial. Sebastian