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 F12C6C43334 for ; Thu, 16 Jun 2022 19:14:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CEC756B0071; Thu, 16 Jun 2022 15:14:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C74136B0073; Thu, 16 Jun 2022 15:14:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B15376B0074; Thu, 16 Jun 2022 15:14:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 9BE3D6B0071 for ; Thu, 16 Jun 2022 15:14:45 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id 763421212D6 for ; Thu, 16 Jun 2022 19:14:45 +0000 (UTC) X-FDA: 79585050930.03.09310F6 Received: from mail-ej1-f45.google.com (mail-ej1-f45.google.com [209.85.218.45]) by imf22.hostedemail.com (Postfix) with ESMTP id EC09CC009E for ; Thu, 16 Jun 2022 19:14:44 +0000 (UTC) Received: by mail-ej1-f45.google.com with SMTP id hj18so3915160ejb.0 for ; Thu, 16 Jun 2022 12:14:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pbV08iBwGfkxmXYoA1VIJvlV2UmK3YzJ41yofRdZyLU=; b=dcdkMcHTJVnxoroJQQyOSQ2hvO4JsUyL9A8pgzbQH+EYSDrJYCrkrswzLz3irfA2j7 efMBNu5K1vFadai8pD+FNsVf+1jorrZW261NR6AFq2WVl/6gy2247A+GRqmGxI/sKIAy Edk+iURnurHyyEsKgmgu6hsjFw1Nfh+9lfQlA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pbV08iBwGfkxmXYoA1VIJvlV2UmK3YzJ41yofRdZyLU=; b=LXxHN+17jvADV69YcwgVbTZngOgEpkjVATDUWeiSYQmYCz563grFyZtzeej05drDWI 25sGqj3APhAukdwMs3ZzP4vdGLKdEDN1F+V5xYF42cXNkyT4XS+fWFz83MdyZoImZ8P/ Hx2bAQKkzqfMotbZSyacrxdBu871iz22KE5klQpGAUnbHNUHCqVyjPXqc/0vdiIn4B+L SUiAqUlxTsiCePZqYHAPJmtkWIsmD/HR+KqrCF4EEW9koP9EZqtmneZWQMxcxQpIpXz2 t3q+unEjy9Q8/PryXS9qsk1LfZa5R4OUlTHUdGiejd/k1vA5h+wHV/GgG3OUlZ/DADCR 60SQ== X-Gm-Message-State: AJIora9KhTYl+Bul5dbXjrbabtnYNRG+gVG5PnAel31s4YSQQgBwl1pY ed91TY42Z2P57XSUWCd5MNc2O5CRfgVP8JC1 X-Google-Smtp-Source: AGRyM1u/5TPTQHzlgx9eE2XiUjVZ9+sLRHqtTL4G1T++LfObKGDHr8b2RKcfcdJmxNtu6XCQSH2Ibg== X-Received: by 2002:a17:906:c7c1:b0:711:d2e9:99d0 with SMTP id dc1-20020a170906c7c100b00711d2e999d0mr5836069ejb.639.1655406883253; Thu, 16 Jun 2022 12:14:43 -0700 (PDT) Received: from mail-wr1-f45.google.com (mail-wr1-f45.google.com. [209.85.221.45]) by smtp.gmail.com with ESMTPSA id v18-20020a170906293200b006ff0fe78cb7sm1105738ejd.133.2022.06.16.12.14.41 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Jun 2022 12:14:41 -0700 (PDT) Received: by mail-wr1-f45.google.com with SMTP id w17so3045606wrg.7 for ; Thu, 16 Jun 2022 12:14:41 -0700 (PDT) X-Received: by 2002:a5d:48c1:0:b0:21a:3574:e70c with SMTP id p1-20020a5d48c1000000b0021a3574e70cmr3982140wrs.97.1655406881201; Thu, 16 Jun 2022 12:14:41 -0700 (PDT) MIME-Version: 1.0 References: <20220616143617.449094-1-Jason@zx2c4.com> In-Reply-To: From: Linus Torvalds Date: Thu, 16 Jun 2022 12:14:24 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] usercopy: use unsigned long instead of uintptr_t To: Matthew Wilcox Cc: "Jason A. Donenfeld" , Linux-MM , linux-xfs , linux-hardening@vger.kernel.org, Linux Kernel Mailing List , Uladzislau Rezki , Kees Cook , Greg Kroah-Hartman , Joe Perches Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1655406885; a=rsa-sha256; cv=none; b=aig04H+Jtj7O6YlluaqtXOGACo0dFpq3lFwKj66pTcA22rof7H5EmaF0siB3JBfakyKcbI CNHpv+t0/C12rWsLp2/tA3IwmF0VDjhLv5fUw1UPMQar3+v8m/46q8yle7orh3bKsmb765 q9xykk/gnku8Fzdvd8CTOZfDPtvG1K0= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=dcdkMcHT; spf=pass (imf22.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.218.45 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=1655406885; 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=pbV08iBwGfkxmXYoA1VIJvlV2UmK3YzJ41yofRdZyLU=; b=iS/aRpvGZclIkBAtsMVL3gqJ+k0fgdAtJ8tnduMXvANcAXQR/3ghDHAvHt2+fNndqYrH4j 1XRTTjC8c7GgjAI2PUp9ydShWnIhIStZ1B5LOZKp+X9Ri1vD4IF5ZWgcsdoiz2Jp38+OJY tG37qNhgY/lrZBDH3/ni2PDxhAmQFno= X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: EC09CC009E X-Stat-Signature: 74ho5x4xz1g8wy9nbtqjmt8cigoxosgh Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=dcdkMcHT; spf=pass (imf22.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.218.45 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none X-Rspam-User: X-HE-Tag: 1655406884-613229 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 Thu, Jun 16, 2022 at 9:56 AM Linus Torvalds wrote: > > Out bitmaps and bit fields are also all about "long" - again, entirely > unrelated to pointers. That, btw, has probably been a mistake. It's entirely historical. We would have been better off had our bitmap types been defined in terms of 32-bit chunks, because now we have the odd situation that 32-bit and 64-bit architectures get very different sizes for some flag fields. It does have a technical reason: it's often better to traverse bitmaps in maximally sized chunks (ie scanning for bits set or clear), and in that sense defining bitmaps to always act as arrays of "long" has been a good thing. But it then causes pointless problems when people can't really rely on more than 32 bits for atomic bit operations, and on 64-bit architectures we unnecessarily use "long" and waste the upper bits. In some places we then take advantage of that ugly difference (ie "we have more page flags on 64-bit architectures"), but on the whole it has probably been more of a pain than the technical gain. The bitmap scanning is probably not worth it, and could have been done differently. And continuing that for some 128-bit architecture is likely just making the same mistake even worse. So I think we have a *lot* of things we should look at, if people really get serious about 128-bit computing. But I personally think it's several decades away, if ever. Looking at historical workload growth is probably _very_ misleading - Moore's law is dying or dead. We're not that many shrinks away from some very fundamental physical limits. I do expect people will want to do academic test architectures, though. It's not clear it's going to be a "double all the widths" kind of thing, though, and I don't think there is a lot of sense in designing for a future architecture that is very hazy. It's not entirely unlikely that we'll end up with a situation where we do have access to 128-bit operations (because ALU and register width is relatively "cheap", and it helps some loads - extended precision arithmetic, crypto, integer vectors), but the address space will be 64-bit (because big pointers are bad for memory and cache use). In that situation, we'd probably just see "long long" being 128-bit ("I32LP64LL128"). That's obviously what people thought back in the ILP32/LL64 data model. They were wrong back then, and I may well be wrong now. But Moore's law limits are fairly undisputable, and a 64-bit address space is a *lot* bigger than a 32-bit address space was. So I personally will take a "let's wait for reality to catch up a bit more" approach, because it's not clear what the actual future will hold. Linus