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 D4DB6C282EC for ; Fri, 14 Mar 2025 21:05:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D88F6280008; Fri, 14 Mar 2025 17:05:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D39C7280004; Fri, 14 Mar 2025 17:05:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BDB30280008; Fri, 14 Mar 2025 17:05:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 9E761280004 for ; Fri, 14 Mar 2025 17:05:24 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 8BF6F1C890E for ; Fri, 14 Mar 2025 21:05:25 +0000 (UTC) X-FDA: 83221387410.25.A2C20F8 Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53]) by imf06.hostedemail.com (Postfix) with ESMTP id 9D8FE180006 for ; Fri, 14 Mar 2025 21:05:23 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=CgPGbh7M; spf=pass (imf06.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.221.53 as permitted sender) smtp.mailfrom=alexei.starovoitov@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741986323; 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=T7w6Uc54Hp4Z4ogU8idzqB5PDjE5SVF81UwFxvxvh5Y=; b=JYcPbZVsKAMqZXCVQOol+/dhgMmp0ZFZ8TSoDAzSS9bxdASgwb+fEkdbjgSUSqoEiM1LiP FxDdq9MQfFda/hV+4jIkns7h5UP1EWw9KCv6eg6fYUmV8zPV5ymup6QGYrj/AD8A95FMVL tY5RsGshL4JcEpoUmRjlkxtJO6KXTGo= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=CgPGbh7M; spf=pass (imf06.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.221.53 as permitted sender) smtp.mailfrom=alexei.starovoitov@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741986323; a=rsa-sha256; cv=none; b=DMGPUsTMspqcVbX8i9azVbs1AGizaoZ/HNH2o5yJcw1CvmihEA9SEzyJqQDmIjSAHUTrga gXwkto6UScDki1b6CfOZ3jY3fi067xLEfB7OhxDQPL6VmHA7Rkatj+LpZmBatKcNaw6dE/ bN1MxwspYrP3hAIbQRLPGq1TVTtj5EE= Received: by mail-wr1-f53.google.com with SMTP id ffacd0b85a97d-39141ffa9fcso2125072f8f.0 for ; Fri, 14 Mar 2025 14:05:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741986322; x=1742591122; 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=T7w6Uc54Hp4Z4ogU8idzqB5PDjE5SVF81UwFxvxvh5Y=; b=CgPGbh7MXEkQJ8Z5pPUEcI2wunDZGKlzuDKPhtdkmryuFrq2A3/Ix31MShUGNoDoBO 2UUVRzh5fHtF+aHKru5mU8GTEfl4sIfizGDFQ8v9O6joWgVhWYex0ivA0RAXtMbwmMsl Q6nbFDtHWCxjDfBQxl16ecYKF+pFKLGfYux/m38jIyxam7pKD6jdfeaidW2bU8/aEitz sg4PknyjU7CakfSv9ch/tdZs22rJzsjgy+XDxaSyrTkki+QwprHTKgFAJNmfuY5d55FO hNeaMw1H36BM16Npmv5bei0kFwuPlT3GBVPEspiRkZVoF0hvYZM01Zdtg38PT0tzjKbs EwwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741986322; x=1742591122; 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=T7w6Uc54Hp4Z4ogU8idzqB5PDjE5SVF81UwFxvxvh5Y=; b=n9b2Ik7lcugSwI7KgMKPChzTrnU7qpqrdszTt4N5s0M5dXT5YzEePXJ2UCMfesWZ68 Xq85nQdamdu9Qx7k+6CpV6lfNAliNQpLEYonAFpZCC/gMqBH0b48mHU4J2QEERjfVcds JUCuTQQKBSsgm4CsJL3/A9GdI7XNoxs5TVVRZDfuCha5CM6k+cz4WhaPNhrDVZ9CRilw s1rdApTlAKd2e62siAaSdipmd5Y94w/jhf3NLQ8f4ekO3egIMmVXxhvy7+gwHkNZZBBY P+QMlo0K25fX6OsrGpRRIMp0+KNWLLPkUmCSe1OPAZqrLS4M8vbxeCtVWvNcijH+W1gB JRVw== X-Forwarded-Encrypted: i=1; AJvYcCX0mXyada6HxJ3ZeVeduFB0gWvRoAHEx/uqVGvrPojh9O4MEHcvjevi3Fqi5ZwRmQ43Iaf9Ih1kTw==@kvack.org X-Gm-Message-State: AOJu0YyhVFprV9+fkEC6LEI+8dw7PJdh0x07bCVym9q/Oxd1S2MGTCQp 1XpCpsc+CAD6XC2fRXfqVe/ayxcsb5IOZ2n7VPOK3gSmVx+NNXlf4/GzRzQfxrFL4aise7r/Qsa q2ww61n4QONu1pFyHQEE0kT0MuQA= X-Gm-Gg: ASbGncvKBPras+cKcFiUJBuPdOKinTf+i5j+H9jMThm2zib2lce0EXUMvemIdYlufKL aLntlLv1yBOgaI05sEC7RKCNZg/BedINqkPflEM9m2p/o44mlqY5z94cr6XRZGNGEGUdsZ+lYYx U9U8SYv4SXQUxYLqQMP6PoHbUtfFVYLz5quIdFzXN/4A== X-Google-Smtp-Source: AGHT+IFo13vCXBHtrlSWgGPCh8y5QQMU4cv7zNOU9SlNZjO1a1oUxuWBBplDhT7izEPAhcVB+QCkW2Zh/58maKTowiY= X-Received: by 2002:a5d:598b:0:b0:38d:badf:9df5 with SMTP id ffacd0b85a97d-3971d2378a8mr4137708f8f.17.1741986321824; Fri, 14 Mar 2025 14:05:21 -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: <496ff0d2-97ac-41f5-a776-455025fb72db@suse.cz> From: Alexei Starovoitov Date: Fri, 14 Mar 2025 14:05:10 -0700 X-Gm-Features: AQ5f1JrTxff2qQvWoQ34z5jQ9hEz8VBsLUFbKhfnN4sPE5bEh5-m8am-auc_V8s 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-Stat-Signature: fx6sjfx7su1nba7txauwaeqe5jxyucaz X-Rspamd-Queue-Id: 9D8FE180006 X-Rspam-User: X-Rspamd-Server: rspam09 X-HE-Tag: 1741986323-220253 X-HE-Meta: U2FsdGVkX18XGLz+LrBA7Ft+2bSYk17dd3G24Cy2FoXzDTwYvBjnB7MhL8PyD9vM4GvKWHQEyo6U4oc9LnGUOMepF2FJq1BaryZb+ENMkLaSgOHZ0pmOWWrx5XE10vZOCDvVNac23Nhsj5hxLdP/kfuhUdi05ILkrLHQUQAhZOfI+PQniaTIoiJc5LflogT8A3nLKdBY4qf8NYglJYEXVu7VSTZlbDU5pewKBDq1rqxnWIBaWnUbQCtUVz4w4Js2J/2o0alhpys7LduyPwbB5gud/5S15G+Eyfn1roPTdXQ2uAA8Fb+2TE4k41RUAdmQa8Ubjxm9XeovWtLAm+qFLWx2pRPiwnikDf5phM0kQ/aEqCtviAlZbUKebq8eP7PQXRDJRt9A1aJJrEZJ8t8HZP9eNBfgKE/dm4Lux0Eh8+BbOBeGuTP4q/qUQjlxqNX6dLev+FG7h7u3qIt5E3tgS7xj5IDkQyVfQFMGqLBXKkk7bgCkjSmurd46Q5qlXnDLlyOL2pNLtmZ0MHB8gFAe8YEIc4128cy9zlakpULZ7EQFLcvyqCKAGQD5snaWfTqQ5TiLNsngWppq6YREKacdE/6QkwLlutqFBzDm11Jg1ruMuAvM5BaadTtguCQSCCOi78w2zUUhfKw7n9S7bwZyZfGf/hiMN0k3dditKWGwbV/rwRh06/IWeHZ8hcEC2sI5ySfLYfUMhAw9BxFHSrFWKcLBKamhoWG7nknTFk0/vGZl9qn3qd/FUEgHZpsadgAEqdeZDnwy7pD3XukHRah4XH+TksmMS2J1dmXeZ5UNxl3Kp2hMmiuiS3g/vKkoO9MmA9iUeJu4y6tFbSW3EBfIBkrRSGUAginn369RU2juaSljPNbtBSzjctIcubYytoTYnRtNA1cfuQppzHPT8u2G9L1eUaX54anS4e/1W0QEZi+LidLSp2PwsTSl16aEA2OgxFXq3j2hfF7xsEs9fSH X8DJ1XY9 oFaNrr8NjGtwG4i3s7p3YB8NP+uaEHmqvUiyXEXMm1XYu6VUG+pRh4KtqWZ9R2ywsKdPIQ4OsALepkZyP4sMACmOpy2NHOUw0zHavq8g9lhmkuurSWq/JDn6CG+iQtN4ENBhGL/QIZZTPTDEQsq+hDjra9ocr3ahxhjK0CH7nwzNNpmzkxEowes6j3m+8zOyO0gZWATGp3OEBVJdFoh6olTSF84iuVJOKhrxqR9CP1CV8yi4njrrKhn3GwWrthTD/Qp8CnYqiq48tyQnxNE0+naxY3xAiXAaixUp79AIHLuoqwaKOZW9uR8wsLX3HQbVl9kHqdTlnDpCenvG3i3+jB+SU1wSM87ztyePtIM4W61vHlRxqVBnxcXppdONuHMPgxcdNnjNdcw60nf+y0liT2mURIYweZQSIe2IPz3mwuFTgXzeF5jdL7syaE1FNjG3Xa0hz 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 Wed, Mar 12, 2025 at 1:29=E2=80=AFAM Vlastimil Babka wr= ote: > > On 3/11/25 23:24, Alexei Starovoitov wrote: > > On Tue, Mar 11, 2025 at 9:21=E2=80=AFPM Vlastimil Babka wrote: > >> > >> On 3/11/25 17:31, Mateusz Guzik wrote: > >> > On Tue, Mar 11, 2025 at 5:21=E2=80=AFPM Sebastian Andrzej Siewior > >> > wrote: > >> >> > >> >> On 2025-03-11 16:44:30 [+0100], Mateusz Guzik wrote: > >> >> > On Fri, Feb 21, 2025 at 06:44:22PM -0800, Alexei Starovoitov wrot= e: > >> >> > > +#define __localtry_lock(lock) = \ > >> >> > > + do { \ > >> >> > > + localtry_lock_t *lt; \ > >> >> > > + preempt_disable(); \ > >> >> > > + lt =3D this_cpu_ptr(lock); \ > >> >> > > + local_lock_acquire(<->llock); \ > >> >> > > + WRITE_ONCE(lt->acquired, 1); \ > >> >> > > + } while (0) > >> >> > > >> >> > I think these need compiler barriers. > >> >> > > >> >> > I checked with gcc docs (https://gcc.gnu.org/onlinedocs/gcc/Volat= iles.html) > >> >> > and found this as confirmation: > >> >> > > Accesses to non-volatile objects are not ordered with respect t= o volatile accesses. > >> >> > > >> >> > Unless the Linux kernel is built with some magic to render this m= oot(?). > >> >> > >> >> You say we need a barrier() after the WRITE_ONCE()? If so, we need = it in > >> >> the whole file=E2=80=A6 > >> >> > >> > > >> > I see the original local_lock machinery on the stock kernel works fi= ne > >> > as it expands to the preempt pair which has the appropriate fences. = If > >> > debug is added, the "locking" remains unaffected, but the debug stat= e > >> > might be bogus when looked at from the "wrong" context and adding th= e > >> > compiler fences would trivially sort it out. I don't think it's a bi= g > >> > deal for *their* case, but patching that up should not raise any > >> > eyebrows and may prevent eyebrows from going up later. > >> > > >> > The machinery added in this patch does need the addition for > >> > correctness in the base operation though. > >> > >> Yeah my version of this kind of lock in sheaves code had those barrier= ()'s, > >> IIRC after you or Jann told me. It's needed so that the *compiler* doe= s not > >> e.g. reorder a write to the protected data to happen before the > >> WRITE_ONCE(lt->acquired, 1) (or after the WRITE_ONCE(lt->acquired, 0) = in > >> unlock). > > > > I think you all are missing a fine print in gcc doc: > > "Unless...can be aliased". > > The kernel is compiled with -fno-strict-aliasing. > > No need for barrier()s here. > > Note I know next to nothing about these things, but I see here [1]: > > "Whether GCC actually performs type-based aliasing analysis depends on th= e > details of the code. GCC has other ways to determine (in some cases) whet= her > objects alias, and if it gets a reliable answer that way, it won=E2=80=99= t fall back > on type-based heuristics. [...] You can turn off type-based aliasing > analysis by giving GCC the option -fno-strict-aliasing." > > I'd read that as -fno-strict-aliasing only disables TBAA, but that does n= ot > necessary mean anything can be assumed to be aliased with anything? That's correct. > An if we e.g. have a pointer to memcg_stock_pcp through which we access t= he > stock_lock an the other (protected) fields and that pointer doesn't chang= e > 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.