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 98734C282EC for ; Fri, 14 Mar 2025 21:18:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CEBDF280008; Fri, 14 Mar 2025 17:18:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C9C5F280004; Fri, 14 Mar 2025 17:18:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B63F7280008; Fri, 14 Mar 2025 17:18:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 9A42B280004 for ; Fri, 14 Mar 2025 17:18:19 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id A0B8C1CC650 for ; Fri, 14 Mar 2025 21:18:20 +0000 (UTC) X-FDA: 83221419960.06.66870D9 Received: from mail-wr1-f45.google.com (mail-wr1-f45.google.com [209.85.221.45]) by imf13.hostedemail.com (Postfix) with ESMTP id B1D7420008 for ; Fri, 14 Mar 2025 21:18:18 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="Y/LJZG+q"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf13.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.221.45 as permitted sender) smtp.mailfrom=alexei.starovoitov@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741987098; a=rsa-sha256; cv=none; b=4fpOo5C6qWBmW+F+4n1SLMk3UQBmA2ojME+RHcuxB26ia8f2Hl2p7zZ7HXUQAPyuVuL2Pe Ms1Dagew8tVs+0iMaIT5/+pg4y44d1XzW5PhlIOXpbu1F7E8sRRhe6vmIg5d/cjEu2I1Ku Us+YVt4MnD8co898Ydml0oMUxrxzbgo= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="Y/LJZG+q"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf13.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.221.45 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=1741987098; 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=VkAtYsDN/lRAhYyBlWsg6XpIv12Yc1rU5UVL3MTjmWM=; b=E2sxjhId+YS4N0SBNSlINcU7NSshTtssf8/TBKrSC0kTUuqYTK9VYDE+NNl5dJMsHhZHVt FZ9DQSOqK8Sqm+Qu4upJDZxYhVzBUsf3gs/mc3YPr2iQILXqYS23GC+AXd+Kl1PIa8CAhb c9hcwEBUcxAbv1NwUBpa5HwX2KjsIC4= Received: by mail-wr1-f45.google.com with SMTP id ffacd0b85a97d-3913958ebf2so1995274f8f.3 for ; Fri, 14 Mar 2025 14:18:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741987097; x=1742591897; 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=VkAtYsDN/lRAhYyBlWsg6XpIv12Yc1rU5UVL3MTjmWM=; b=Y/LJZG+qrqUdxy8khMuPO9wiqdQTkZZW5zAI4IbaLSlqmXpZQhuUwkSHsDZ0jbzyIP /W+f0itK09md8elDSJnWAXWB0TWSASW1qLjWjyMj8v7QDc2BOlEnMkq7f7msS0IfO44K KFGHWu3LBFhTUz65a/JfEm3ZPSmv2CEop4dfl6V1hKyRkshxVXFPrz/MexWN4BlQ+ZN+ 7x1W4s56nJc/nUmx5QMil91QCP9SMg+2RkrgVQKxvc0e/kQSiHuxlO4gi2znpQ/TBA1I 0a2Ed6lB4T6/+zcS4N32+y9nlWQ80oxbdyAu7Ycjhz0yNmYJGdGtRCYDmYliO5keqK2c wmgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741987097; x=1742591897; 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=VkAtYsDN/lRAhYyBlWsg6XpIv12Yc1rU5UVL3MTjmWM=; b=phXIcrJ9XxpZkfbNkzbucLg/jnvfdqIZ2c+yKvwtX+kl57TXduD0n6IeKMSvCT0gkB fhbA/uql8HGA7TA3Qn8VmQ2ult1mYmJNeecvm8kee/FdRlghY3YSYfa2cZ/Z4uQe0j+t VVvw19kIs4SU5N2OGMRtG94z7bw6O9sfXTrMC1Tdsi13L8foJeFSP6xSL5/g7oQEbT/I aCDCRkiwf3TIzbe8cdbveN3l2AQAQmXttEUYRXurpGZ66Xr89eNfVOWPF5e+KzOMp20T 1BfH+sNVu4hDvC08RSogUI8HGyeNfykg3gsTtHmy1iR3Lmcz6Y1cG9aShY1AFZ6jH+n7 CYDQ== X-Forwarded-Encrypted: i=1; AJvYcCXk/GFgjCCrjfjMwN0fOK3mh/jCpBwdDT7l/tUdTwxOj5oX1+yEJRUGmWJ3Y0OL1fEOqx9ld3elfw==@kvack.org X-Gm-Message-State: AOJu0YwVlDyf44hcJZWab5R/OWIw1tQarXYzpEwp7dxW3mp2zQbj78iR DsAzHktXvaIHoTE+ekQjMnQzBOAucF2pKvDC/awY1/xK2Rcw6oBRKxtNXfoOCwG0tySMQVSlLpT 2+gvqse4gUc9T5FtTKOEuY8Mp9U8= X-Gm-Gg: ASbGncuKXdFxUHXAXWJSrSaYI0CQ0RSPEV0EibskgX/YVOYiiD2hG65cUBvKSThOG7d lah/GUvXqknfcbWC8QcCEqDdmd0gqRPLoFo4LBjCsabIdlx6/r83jCLU3PtfpB2LW7cNTox7Wrv m17KzusXO/PWxKWEGF6kPZVqXzYIL4LtAFacE78ntXFw== X-Google-Smtp-Source: AGHT+IHi7eVc8OKSnPQTa6FoFbDKV4U+3MMoEemj7DQDHnE36dRNlyylP++snmK2/RJToqSwtAGHbcwU0T9OH7IkrZg= X-Received: by 2002:a05:6000:4709:b0:391:4390:97e3 with SMTP id ffacd0b85a97d-3971dbeaf46mr5460787f8f.33.1741987097011; Fri, 14 Mar 2025 14:18:17 -0700 (PDT) MIME-Version: 1.0 References: <20250222024427.30294-1-alexei.starovoitov@gmail.com> <20250222024427.30294-2-alexei.starovoitov@gmail.com> <20250311162059.BunTzxde@linutronix.de> <496ff0d2-97ac-41f5-a776-455025fb72db@suse.cz> In-Reply-To: From: Alexei Starovoitov Date: Fri, 14 Mar 2025 14:18:05 -0700 X-Gm-Features: AQ5f1Jr9dYikWutmxvIH9LrULiizPorg3RV6Am3YULy0KDxisqlH9F6mebSZBG0 Message-ID: Subject: Re: [PATCH bpf-next v9 1/6] locking/local_lock: Introduce localtry_lock_t To: Vlastimil Babka Cc: Mateusz Guzik , Sebastian Andrzej Siewior , bpf , Andrii Nakryiko , Kumar Kartikeya Dwivedi , Andrew Morton , Peter Zijlstra , Steven Rostedt , Hou Tao , Johannes Weiner , Shakeel Butt , Michal Hocko , Matthew Wilcox , Thomas Gleixner , Jann Horn , Tejun Heo , linux-mm , Kernel Team Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Queue-Id: B1D7420008 X-Rspamd-Server: rspam05 X-Stat-Signature: tmqhxsiqaji1u3mwj71wuqptm7ouc71e X-HE-Tag: 1741987098-193573 X-HE-Meta: U2FsdGVkX1+1GGmEYyzXJzLmTkhx3gRPokWp9Radc9hPUaXbpnp/F/7/sVPFwnEMjrJGsBwFh6IpPCztbGA9+xnt37US83JIUtu6k0It0O88PbOaq2GxDnnYacBNpUnN5P9qeZu1dii9cDbrW6hP3d+iswH4WSRJSQ0QRGkElpavELIaUKdPhdaHn6+ShAUE+hLTeB7irBQoR6qZbi4VA/6Q+BDv1/IKrKig8T2ygkegRFTPdmGo43G8Kypa6yDDycWu5VoLw8uFxW4jMuOPda0kqiMht/aLnnZ6l8YhuJwedbrt2IR1gKDzZTcgYKXbLd5n2zhw+w7FBuB5MHCo//62nSmthr3YKGLcBgc4sEn/NJlsGGlHQTadHlnj9Prqy4Zv6FToqdslpwW0qZ1kZIj8e0DNTnq/cxQhjyO26qnkaGBk9vEWogwB35X8W107E+vtfU7EIbnpgyIY05WK5IqrioGlsox7RlCMMB0/5edV4ss92jiwOHnbCs/QujHUnpTZb8vz5k0HxwpdD8LAGn0H2cPMRx47nuG3NEBBrE81R+qrrHYIgmuti7fVbrsGOw14gfZuk65XQO2k2m+cuHYxtok6wf9BYlX2JHDukwrc8GBg2osyCon5nZy0k/VRKn13sPL7g3L1+IHLSS6m2VtNWiblBk/G5oW4y7fj8ZDLBmJpzQ3fFX4TdykylLX9+kTo/RC+w1qmoVxU+U10fHE2v6hTxbVsNer3nRzMdo8BlMszDn2B8fly2h8xjkNVczGpUKLtJMXgNBgBDAuZtw/C8ucJFuQGYMg88m8V2Y5eEFo8AhWmPzpISv1EUJajPqscNCeOsRdjO1Y7eIMek7cOcJ9nuMDt7dBTtvSvmYxB7dUXVNGBtkkWdwENvunjsXVSFncgQXtLdwwVtqef74DR5z5nt9I/UAnPln99u7vxZXdHTcpNHvJ3WRYMC59Hd6DdU1agNIDkW2pBQCk yIm7s4aF SNVqieE1W4m7y9oXx4gHfepaanHFwlH+F4OBrPsM/hl+b2XWGO6ZZ9YYBj1ktnP1WCvL7NVLKppNb/creFfCJx94J3hKNd+GESeuHsN9dT0F8tsrUEgIjHWSqwgPpirBAheE3Ke+L3xOE64mFj2IQs8uV8qeD56heGv2Ubgvxh7t/KQ+NHKx4TYpx+9DwnC05o3574BilqwWLhpkWk6xSZqStUoHO7/S4NShk0I/N/XhPLiMPexaWBkdY6QHRePZ1I3WfmbvPCvFbH7nhb0BGmoL6xdwLycQh5skKZUjZJkM5cp2n91cE3PAodaW+PJeb/OKgzhKrt2cBeGyYT6DVwY0bw3QCr7lfU17ZIae7QDH3Cx05KA/+1LDAxW+3G+AanPQFiOz360FkQd0= 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 Fri, Mar 14, 2025 at 2:08=E2=80=AFPM Vlastimil Babka wr= ote: > > On 3/14/25 22:05, Alexei Starovoitov wrote: > > On Wed, Mar 12, 2025 at 1:29=E2=80=AFAM Vlastimil Babka wrote: > > > > That's correct. > > > >> An if we e.g. have a pointer to memcg_stock_pcp through which we acces= s the > >> stock_lock an the other (protected) fields and that pointer doesn't ch= ange > >> between that, I imagine gcc can reliably determine these can't alias? > > > > Though my last gcc commit was very long ago here is a simple example > > where compiler can reorder/combine stores: > > struct s { > > short a, b; > > } *p; > > p->a =3D 1; > > p->b =3D 2; > > The compiler can keep them as-is, combine or reorder even with > > -fno-strict-aliasing, because it can determine that a and b don't alias= . > > > > But after re-reading gcc doc on volatiles again it's clear that > > extra barriers are not necessary. > > The main part: > > "The minimum requirement is that at a sequence point all previous > > accesses to volatile objects have stabilized" > > > > So anything after WRITE_ONCE(lt->acquired, 1); will not be hoisted up > > and that's what we care about here. > > OK, is there similar guarantee for the unlock side? No write will be move= d > after WRITE_ONCE(lt->acquired, 0); there? Yes, because the first line: lt =3D this_cpu_ptr(lock); WRITE_ONCE(lt->acquired, 0); this_cpu_ptr is pretty much a black box for the compiler. 'lt' can alias with anything before it.