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 EF567C28B28 for ; Wed, 12 Mar 2025 08:29:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DAC1F280003; Wed, 12 Mar 2025 04:29:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D5B24280001; Wed, 12 Mar 2025 04:29:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BFEA3280003; Wed, 12 Mar 2025 04:29:20 -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 A177E280001 for ; Wed, 12 Mar 2025 04:29:20 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id B999CB75AB for ; Wed, 12 Mar 2025 08:29:20 +0000 (UTC) X-FDA: 83212224480.03.EDACF7A Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf10.hostedemail.com (Postfix) with ESMTP id 65271C0005 for ; Wed, 12 Mar 2025 08:29:18 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=NJG+hdaS; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b="ZXlk46/t"; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=iNgGKjWW; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=HEXuedyH; spf=pass (imf10.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.130 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741768158; 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=VFDcyHv2rPhwU7HSFXM2u0+Uk0NgStzkjPXTuZ52N0k=; b=L7R5IJky9kKA+AAZvMAmi0NxdQF2BU6p3aOd1CNxe5Gmk8xhfpShDs1D8VPEbZKGR//b4H vu06wSdcNgAP2zHhw9HK/rpMU4FwftLBnA7xvYdPqYQEQBiqyBRSp5Gm3D9/G29IUT2Ogq N3aap2R4qamOGTv909QImP0HTe4zTBM= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=NJG+hdaS; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b="ZXlk46/t"; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=iNgGKjWW; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=HEXuedyH; spf=pass (imf10.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.130 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741768158; a=rsa-sha256; cv=none; b=NwebHpGLGrfwwD/Oezs8yrkC8e1emZsRUWOV84tnDNMkscCVLEMF7HMTZ6XX9SBmsqqYnY UftF71jjFRHbbQiMsLT1YGkevpyj56rj3Cy4eFBOaL6mX/pxWWXP5vqY+yDPl6HZRFVOaY 1fdTpGH2ez3fKufpFvPS7F67gEv9XKU= Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id BF1F721191; Wed, 12 Mar 2025 08:29:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1741768156; h=from:from:reply-to: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=VFDcyHv2rPhwU7HSFXM2u0+Uk0NgStzkjPXTuZ52N0k=; b=NJG+hdaSsz+sygZ+7Q5chLxj8q++v2OF3xy9EKD2uS59UUv7PKyFcA7wBo7cowZzvWlG4w T1ua+p5cCOhvoHqKuCLLJUXUeGwwGq9IlDY1RBprn+5GwuRu035fdcZAx0IjFEvlHvg022 4MjhWxnXiLZbOaJO6zBnChGVp6V67Gs= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1741768156; h=from:from:reply-to: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=VFDcyHv2rPhwU7HSFXM2u0+Uk0NgStzkjPXTuZ52N0k=; b=ZXlk46/t3khFnobzM8MonAhX7ymwC3DAmDOpGPI7kpujJaPeEOI2qDVR+GATkIAFSi6luz 5O1NUHjJbGXvQqDw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1741768155; h=from:from:reply-to: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=VFDcyHv2rPhwU7HSFXM2u0+Uk0NgStzkjPXTuZ52N0k=; b=iNgGKjWWqubMBXc2AHhQsOsTIU9sEidWc3AjJCWYYFIphXJfz5D7CJ7+MQvfyQH5IhHKUu GKK8g8WUSBrZodybV0FX0PA2rTFMQNRCitzgi7u2OsxeDz4aOsFvPq7IQnKkPLlCvlUK36 N8X/DhgR71u4MkD6uuc+cQ8m/e3vz3s= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1741768155; h=from:from:reply-to: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=VFDcyHv2rPhwU7HSFXM2u0+Uk0NgStzkjPXTuZ52N0k=; b=HEXuedyHxqfgk7Szj8oplCnUOA/UjOXNudhDqrDaW3xHDt35CaZ+CbXPE84nF4sMOThpN3 ncfuc6if8IDTE/Bw== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 8C84F1377F; Wed, 12 Mar 2025 08:29:15 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id syL1IdtF0WeFfQAAD6G6ig (envelope-from ); Wed, 12 Mar 2025 08:29:15 +0000 Message-ID: <496ff0d2-97ac-41f5-a776-455025fb72db@suse.cz> Date: Wed, 12 Mar 2025 09:29:15 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH bpf-next v9 1/6] locking/local_lock: Introduce localtry_lock_t To: Alexei Starovoitov 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 References: <20250222024427.30294-1-alexei.starovoitov@gmail.com> <20250222024427.30294-2-alexei.starovoitov@gmail.com> <20250311162059.BunTzxde@linutronix.de> Content-Language: en-US From: Vlastimil Babka In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Action: no action X-Stat-Signature: s4efdz43i334w4krgbefp1kcacmi3zaa X-Rspamd-Queue-Id: 65271C0005 X-Rspam-User: X-Rspamd-Server: rspam09 X-HE-Tag: 1741768158-622023 X-HE-Meta: U2FsdGVkX18VUHjV4I640vHIm/1fdLBzaZgqrvlhDGzpnn9fAphrMm3ai53yPDr+H2KUVKzk6JQ7rSG3JbCb6FpxdTWJnFQqzD5+NQFp/dwzwmvrtHvRsR4EoOXkmjC/hyZ8efUP1224mLFAjK0+FMsl9hQHPNSS/OrNx7AE1Di0iim+1zwtFD7YE09ffNJ4MHRyiJQ+xKV00NihkxWFztAbExxYdzkPJ08uBkLH307yff1RhsXKYjKcwH8aW616N7v4Np1KmucP5pft7Jbc0wx1ZDjcEnqDnOWwxSLZxbO/SUBJCQSUhWIhimDM0x+HO2FeW+gzUA0SF+rpopebZG6KJJ20SISc8uilWScshqJi1+kmM10YtccI1UdDmdOgWMdD2jENtKp4nfO0o/kdLmLxwm6ikUl0CmJqWl2sXEyTG5zEXgb+jPYV6SMH23TG2htnaPOwDoxVcfQgyYSRvST41XUXQB0rLO7lpDao6iopiuScszKH5ZHQ1YoZp7C7IzbPUTdFrYpmqS0e0qlbpDbXTiEhQh+FEZeSsjWrerbFLW3sFxVPN89291GjBnKuHv85GyNmiND0rfEtiteB4K5n+6jzLjpY3lx1Ukny5R3lXMfOoyx9ZZktj/7LTA9jK/9IHbjMd3055uD76Jbjka5GU+vErIL8nixmgdZHvnNbTjWhiIoIKPPmavEgBX1bZVjOrdPLDV+YoDLEuksJ0DH/amDFZyAwEhQZ5VWfKdtFYHMMH17AH5wMBXI15HJQwtCn+dL3Ad4QDKOAE/PniZ8Ysr5uEEstiC8hc9AjddsPQzY4Eg+NHhD7fOtctq3Y92ST82GhlKrm+heENhfByXggf8gDiiTf/m/LKZ5Fou46TbmRLhlNZWaHD9cILlQ7b1MTbJGOz5yRuqqgjTxfnLyaCakMckU6d47n0YbsGjMTG5E+sySPtS6Jyp5Gh/89vZqL/ZNge7WwDjR1ZQo MPbmOpwZ aELB6Sgs5VKM243VINJti9/JnG+mSdIYtw0cGlnxhoym0Ng/vC7mfjmSkGdTda74pjXBeiGOlOfhf6dJDkNDOm878qiAWnmLKe/F2+hIJVwAdInoZ18LYrslsWYp2JzU3wOtnhlB5cY9VxLKIl8mc4X+am01WtJswAxQ+hlmtYuFcyiuZwjriW4j2vmHTJRaax/fWHxPew1tSCpxhapTEHDWBXvGLZUnc8fNW9tSDm6g/MQjaSFCSI7/OLBlYBqvSx1EVdWxrpLjk94cwub0SIVWcolnXU8NBU1DzcIOrScaULhfeVk2Yb+4RiwZ2OEuH+hC7u/HT38pqkm67p3HpBX07kO3mOVRnKOUwuSZmEr/RqY2EaYSCaI+E/FS0+LuQoSROOmm5YiVhcUMxmwvGw0dJNAt5p20gK+zSH1vNIM62SWqxYLOAAWfbGoZH+hOJnzolyX5J0AlR+HMGX5yFYqVHvc77vEUH1WawG4EkxTrG0E6z+pfUqPzmWvIZsRJwDQXG17BK/NPsnuoT3DZZyRHIBrPQQohDnn886E5cLISVv+bkbEoFWPJ56w== 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 3/11/25 23:24, Alexei Starovoitov wrote: > On Tue, Mar 11, 2025 at 9:21 PM Vlastimil Babka wrote: >> >> On 3/11/25 17:31, Mateusz Guzik wrote: >> > On Tue, Mar 11, 2025 at 5:21 PM 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 wrote: >> >> > > +#define __localtry_lock(lock) \ >> >> > > + do { \ >> >> > > + localtry_lock_t *lt; \ >> >> > > + preempt_disable(); \ >> >> > > + lt = 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/Volatiles.html) >> >> > and found this as confirmation: >> >> > > Accesses to non-volatile objects are not ordered with respect to volatile accesses. >> >> > >> >> > Unless the Linux kernel is built with some magic to render this moot(?). >> >> >> >> You say we need a barrier() after the WRITE_ONCE()? If so, we need it in >> >> the whole file… >> >> >> > >> > I see the original local_lock machinery on the stock kernel works fine >> > as it expands to the preempt pair which has the appropriate fences. If >> > debug is added, the "locking" remains unaffected, but the debug state >> > might be bogus when looked at from the "wrong" context and adding the >> > compiler fences would trivially sort it out. I don't think it's a big >> > 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* does 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 the details of the code. GCC has other ways to determine (in some cases) whether objects alias, and if it gets a reliable answer that way, it won’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 not necessary mean anything can be assumed to be aliased with anything? An if we e.g. have a pointer to memcg_stock_pcp through which we access the stock_lock an the other (protected) fields and that pointer doesn't change between that, I imagine gcc can reliably determine these can't alias? [1] https://www.gnu.org/software/c-intro-and-ref/manual/html_node/Aliasing-Type-Rules.html