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 AEF93C5479D for ; Mon, 9 Jan 2023 22:08:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 284938E0005; Mon, 9 Jan 2023 17:08:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 235098E0001; Mon, 9 Jan 2023 17:08:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0FCCF8E0005; Mon, 9 Jan 2023 17:08:16 -0500 (EST) 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 022908E0001 for ; Mon, 9 Jan 2023 17:08:16 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 991B0A10E7 for ; Mon, 9 Jan 2023 22:08:15 +0000 (UTC) X-FDA: 80336649750.15.4D8030F Received: from mail-vs1-f53.google.com (mail-vs1-f53.google.com [209.85.217.53]) by imf06.hostedemail.com (Postfix) with ESMTP id C6ABD18000D for ; Mon, 9 Jan 2023 22:08:13 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=F4QSW1fm; spf=pass (imf06.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.217.53 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1673302093; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=k0nIhdmoq2YN+8CYmcGGz5g09uBL17k5HRqIgJjfUJU=; b=jMaq4aoWbzhLbMzNahyTc/VrgXH3aj/BMJhMvkJdelGVhGad4ZN/pGdhCPiOIc1rriOfVJ FtvJpXCpUKxwh39zvmQDdtUcsS7WZdDQtUsVaBK0GDryuLDQOCqTuN9fi3YuBD8fcYweqo htFqjsxrMcErM5wOolJS5+R1iaAKtto= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=F4QSW1fm; spf=pass (imf06.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.217.53 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1673302093; a=rsa-sha256; cv=none; b=Nu+/GoI3JhENBUUYmVMIkjc34OlePtrc0ZSWP2oQBtk3vaISyNghVgp5x91XSXQvxBGYqS clcyeVYnt/+K+Do1gQ/u/8lZpQjQCUO4faMghNiDRyX6unb6Z3xlIWEzBk3B01OBpq+/tQ Dc7t/KWewRPdDG06K5sVIcOtjzWrkJ0= Received: by mail-vs1-f53.google.com with SMTP id k6so1421929vsk.1 for ; Mon, 09 Jan 2023 14:08:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=k0nIhdmoq2YN+8CYmcGGz5g09uBL17k5HRqIgJjfUJU=; b=F4QSW1fmPta1SdZoMgqppkBUl/S595vxphelnA2n0Z8L7+V9JICv9+FhFq2SezihUL AZzzhDrgCA39Hc/bNA+TttzJcb5t9eNeDk24AJ2XPx+BNVsLNoozshq0sopE0CVIK+mb mldZC1Aw99FFSuOlyX98h9PUcGiDBvSvEDfSQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=k0nIhdmoq2YN+8CYmcGGz5g09uBL17k5HRqIgJjfUJU=; b=Q03RUSZGOpfIu0a/rQlxqG4dpVREJGnyvSubStoqUjjz3aB2jc/V+AZY+civdWWuRP 2Ct1kuvxpgg/ro6sr0kV1dhCTCvDsqz7QWS+GCFKOKYiGU6VFnHeuDBQJYSfBSsdQK5S sn7mHDUwW2isJxfeErB60RzBHGTP6WgR8X6ZdO1T/AnVXgLA3Um5O+66F2+hAdaLkAZh mhSBZx6H7LrOeTaM6SMmiUNXxc1RFFkel6hU8ufGyVHly8emdy0Y9Rjldwi+xQ952h0d wQ/cX35OPi+N+y25+o/XP1rxbHvUP//0Y7TLz7ms/PgePDZBfpw0SY9dtVXuGxqaL8Nq Dpuw== X-Gm-Message-State: AFqh2krSfcA25y9bE9XUkQF89QjUWnzvxyiEK4aZfZgiZCAcJ/xrYjQc SVSiZUgTGVGig1Ncjl0iY+pZ5g3izxR8RPD7jro= X-Google-Smtp-Source: AMrXdXvF6P+1MG9uyL/69sLYEd69LDYpSNJmBM3iRD1nJIThyak2BCOyYE3XjO/QhYscv2dt4W3/Ww== X-Received: by 2002:a67:f48e:0:b0:3ce:e81e:323f with SMTP id o14-20020a67f48e000000b003cee81e323fmr6325333vsn.18.1673302092613; Mon, 09 Jan 2023 14:08:12 -0800 (PST) Received: from mail-vs1-f51.google.com (mail-vs1-f51.google.com. [209.85.217.51]) by smtp.gmail.com with ESMTPSA id k4-20020a67ab44000000b003cb0f6a82d4sm1077808vsh.28.2023.01.09.14.08.12 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Jan 2023 14:08:12 -0800 (PST) Received: by mail-vs1-f51.google.com with SMTP id n190so6448891vsc.11 for ; Mon, 09 Jan 2023 14:08:12 -0800 (PST) X-Received: by 2002:ad4:4150:0:b0:531:7593:f551 with SMTP id z16-20020ad44150000000b005317593f551mr1338900qvp.89.1673301769392; Mon, 09 Jan 2023 14:02:49 -0800 (PST) MIME-Version: 1.0 References: <20221219153525.632521981@infradead.org> <20221219154119.550996611@infradead.org> In-Reply-To: From: Linus Torvalds Date: Mon, 9 Jan 2023 16:02:33 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC][PATCH 11/12] slub: Replace cmpxchg_double() To: Peter Zijlstra Cc: Heiko Carstens , corbet@lwn.net, will@kernel.org, boqun.feng@gmail.com, mark.rutland@arm.com, catalin.marinas@arm.com, dennis@kernel.org, tj@kernel.org, cl@linux.com, gor@linux.ibm.com, agordeev@linux.ibm.com, borntraeger@linux.ibm.com, svens@linux.ibm.com, Herbert Xu , davem@davemloft.net, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, joro@8bytes.org, suravee.suthikulpanit@amd.com, robin.murphy@arm.com, dwmw2@infradead.org, baolu.lu@linux.intel.com, Arnd Bergmann , penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, Andrew Morton , vbabka@suse.cz, roman.gushchin@linux.dev, 42.hyeyoo@gmail.com, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-s390@vger.kernel.org, linux-crypto@vger.kernel.org, iommu@lists.linux.dev, linux-arch@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: C6ABD18000D X-Stat-Signature: ip116opi666zq67o3i5g8qzpxnd9joom X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1673302093-869203 X-HE-Meta: U2FsdGVkX19m0KlnjSUB1Qv7FDPedsBN1VqRsBvAavAggld3FizZAi9785NYUF9XtNaBL02BovFT27a4szEt+cWPpsPJxwSor7u4/cgVG5aiUNlny9HLPiCTfEnje9FdCF7oi+YQXbbG1xEXC53vTUGN9tUP8E5jt8fleResecya7nhVAWeXxtt9C1q5LbQnPxKhoYshSgM27+Y69QrB/3QQxCbgjD1BKowMcFF5/70ktX3Tmn6RKh1n6wz3xFttJH8Y+VpADQPK71ipZx41Hj8WrQmmPhaoSFPi64hSihGWYg7xXfbxNa3CUIdTzJ5N5cIdiSHpHw3z9zf5DZWbbdLxr9AnQ7sBHIZ/zEZriBxqYTDKSp0WnGu/9DLd3rJP9jsoCDyZ8Nz8XdBJzvHONWwxqgr+/NnLZrYrFnrsxEwK2ReQJQWibTrJsIgXF5twMrzZLJQQdV+JLlzqxvxDo6hnl6nXRYXyq7Ki5WXrfsGCrCjnXAG9z9X3KhQ+x1Kc5tpw0R+A/y0sstD5oIW+G7bUv0lRM7LpA/rz8Z96QLcCLBs594JTfp4Q4jMMVMYzaYh6Rj48DPk1QO7aaqKt95FWUy9JRV/iDkLe4Ks35jYHgLxtOYuLfOjeG9Y5VJvscTkfg8BOHZk6Zy2T4BjYjMeFo6mdY7FImDjxFQuK5+5MbsF99n0yZh9AS8py6Vhub3/mM+9WGhvy1+S6T7yuSjEMOSNmgBRN6gbZavqim5lj3vCLsq1PC24pkn9Dglgr5ywKC35FQmA97jfJpIwLSD6fjOeNVC/d5gflN7sWk95zfrL2wmUCc6mnHh013OsgmXkQF56j16cutUuo4qwgfU0td21MFf0olVHI0gvoi32p6EDxbjv/z142JZTN3d9h3fWRYRkoT3ORNRkZ3vEg6sze8/QfK4uOkAu8sewfNaByB3ujLCnWLN7LFqpyicZoqnUz/tm04n7Tf+A35VG c9Kr8wMw 2EltUnFru7tDVp0gHl0+qpjRDooFTid9O0UffsBCk0rEBDNuwc2cySsBKpqlvg5AUpyIL3uOCLmx/fWgtqhIN7VeyrRuVbBQtgQ8ODcpAhTX/QxbZ6NOEmOV9nID1J2dKODC4gjM62Bxi7MEiyeyUwZQ6XkhkaJviD/tE6tHUqJxLluUbjEarzv2XMpIR8ye1c2WV7cI8MxvhVEZ27xOgfs5Rx/kwzmUxxKvjYprjZidTRggO3TQdazeT8s9nzG2sB7d9scX4fwPWV1ExfJdLbLu5Ng6SjGx5xe9gVmNmUYc8bBNqTBNhyAca0DbU2/TW/d/1spPFCIM+JB7nCgGSoyBT7dahTGw+x0w0MrqRCKGdaeIxdME+iKpXoOxFZNQUpofHIcUS/x3MpijuyTaTXo8Fjg== 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: On Mon, Jan 9, 2023 at 10:29 AM Peter Zijlstra wrote: > > I ran into a ton of casting trouble when compiling kernel/fork.c which > uses this_cpu_cmpxchg() on a pointer type and the compiler hates casting > pointers to an integer that is not the exact same size. Ahh. Yeah - not because that code needs or wants the 128-bit case, but because the macro expands to all sizes in a switch statement, so the compiler sees all the cases even if only one is then statically picked. So the silly casts are for all the cases that never matter. Annoying. I wonder if the "this_cpu_cmpxchg()" macro could be made to use _Generic() to pick out the pointer case first, and then only use 'sizeof()' for the integer types, so that we don't have this kind of "every architecture needs to deal with the nasty situation" code. Ok, it's not actually the this_cpu_cmpxchg() macro, it's __pcpu_size_call_return() and friends, but whatever. Another alternative is to try to avoid casting to "u64" as long as humanly possible, and use only "typeof((*ptr))" everywhere. Then when the type actually *is* 128-bit, it all works out fine, because it won't be a pointer. That's the approach the uaccess macros tend to take, and then they hit the reverse issue on clang, where using the "byte register" constraints would cause warnings for non-byte accesses, and we had to do unsigned char x_u8__; __get_user_asm(x_u8__, ptr, "b", "=q", label); (x) = x_u8__; because using '(x)' directly would then warn when 'x' wasn't a char-sized thing - even if that asm case never actually was _used_ for that case, since it was all inside a "switch (sizeof) case 1:" statement. Linus