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 428B9C43334 for ; Thu, 16 Jun 2022 16:56:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A47FD6B0071; Thu, 16 Jun 2022 12:56:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9F5D76B0072; Thu, 16 Jun 2022 12:56:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 896AE6B0074; Thu, 16 Jun 2022 12:56:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 75EC56B0071 for ; Thu, 16 Jun 2022 12:56:41 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 3690E31E55 for ; Thu, 16 Jun 2022 16:56:41 +0000 (UTC) X-FDA: 79584703002.02.4943E9B Received: from mail-ed1-f52.google.com (mail-ed1-f52.google.com [209.85.208.52]) by imf25.hostedemail.com (Postfix) with ESMTP id A4740A0039 for ; Thu, 16 Jun 2022 16:56:40 +0000 (UTC) Received: by mail-ed1-f52.google.com with SMTP id d14so3000710eda.12 for ; Thu, 16 Jun 2022 09:56:40 -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=uTCaV5JT6qTWfBercMWlEblUINgIroVSHoW1wsfqACA=; b=W/pKji3dzXG2dNNpq916uSWl5jFc93ncSgWCT1FLBNPdcdyU37WPots+mUlg8QFXpW x1HOB4tio+3irqKgHluIkU8EUtDH1JvErcIqEdlhfdLrDXbaMLfRZOty85GeVeZq3KSe eDrpQOdjX0+ps7jM6+FMhcEQ5Wk/D9zZWJ9KU= 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=uTCaV5JT6qTWfBercMWlEblUINgIroVSHoW1wsfqACA=; b=bg21PdNiuR8ePgGvYPpVgGr0PRfz/0zI1Hb7jAAHgeqqGCNsDeSjrjE6mlLDZ57cQc bZidnKEawBV4izI+Zu1+0p9wzxyLS3X5jxtxtsLoQ5C1aJuqRckxTQ15y71kb3MmAM0U b6U3aWJ4AI1YoUyfGAxKCj8HTnlw342za8XMf/0WccS24jK/TwM/9Q4xgDzAIWxz/Odc 8z7vcA3B67Hru4yr6nVzBpDgvgPSZxPtowgwW/QnmK5smkvDdHtwhgZFVWKXIPew5P7U kbsrk8kohExEU4kz8jH8PG3jbjdNLTx8rkTOxB56YeND6ZbTgiBUk4OOsPL5M5qUMkiv ZQFA== X-Gm-Message-State: AJIora/1M0G6fEto0hXczLCmnf9Qy7jnGjUrMJXD+x7h1Un5s8gQfJDr UqwY81b62vDXfc1+tUpjkT4vp8muFtSFj+tDdDg= X-Google-Smtp-Source: AGRyM1sThkD16IAQ7N+Klxjb7j4J8b/hTlOurHS/Y9iEdb2wrFbiUBg/OJzpdAauHlo3xgfDoz9XYQ== X-Received: by 2002:a05:6402:13cc:b0:435:557e:6325 with SMTP id a12-20020a05640213cc00b00435557e6325mr3036716edx.83.1655398598997; Thu, 16 Jun 2022 09:56:38 -0700 (PDT) Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com. [209.85.221.53]) by smtp.gmail.com with ESMTPSA id r17-20020a1709061bb100b00711d88ae162sm1005775ejg.24.2022.06.16.09.56.38 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Jun 2022 09:56:38 -0700 (PDT) Received: by mail-wr1-f53.google.com with SMTP id w17so2640919wrg.7 for ; Thu, 16 Jun 2022 09:56:38 -0700 (PDT) X-Received: by 2002:a5d:48c1:0:b0:21a:3574:e70c with SMTP id p1-20020a5d48c1000000b0021a3574e70cmr3516296wrs.97.1655398597730; Thu, 16 Jun 2022 09:56:37 -0700 (PDT) MIME-Version: 1.0 References: <20220616143617.449094-1-Jason@zx2c4.com> In-Reply-To: From: Linus Torvalds Date: Thu, 16 Jun 2022 09:56:21 -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-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1655398600; 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=uTCaV5JT6qTWfBercMWlEblUINgIroVSHoW1wsfqACA=; b=3L8isiSmSz07dKUbwQkBCoWCbJ5qtgAOEye3rwecSwL9kEZ+zqIWbwU90OSGuFC8qH7lg4 +GVgkDQj8kDiZXSbAaQrqEWPldoZiLd8cDldGaKWaZwxnRw3h/Lew4EZYoAwJXlO99BAEZ Oq1rTpkOqYFRFJrMHwI+KjURiLRzLtA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1655398600; a=rsa-sha256; cv=none; b=DFpIscOZH0maK4NMduEws38s0ZP4wVibvbrR6oehY4cHWVNyp/rdeIL2LE/cjavHdwnOqM FMAXptFQZjA0++DlYd8W4euZrUsrP0cvfWL/wFPtmND9FRYAgUJWdM+aJ/xNhFnTw2jYaH fmHlucI529K9s1CJDFFQLTg9frmKCto= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b="W/pKji3d"; dmarc=none; spf=pass (imf25.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.52 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org X-Stat-Signature: txs5a9unjwaauegjrh8iikp376q7a5ko X-Rspamd-Queue-Id: A4740A0039 Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b="W/pKji3d"; dmarc=none; spf=pass (imf25.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.52 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org X-Rspamd-Server: rspam01 X-Rspam-User: X-HE-Tag: 1655398600-412718 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:44 AM Matthew Wilcox wrote: > > I don't want to support an address space larger than word size. I can't > imagine any CPU vendor saying "So we have these larger registers that > you can only use for pointers and then these smaller registers that you > can use for data". We haven't had A/D register splits since the m68k. > Perhaps I haven't talked to enough crazy CPU people. But if anyone does > propose something that bad, we should laugh at them. Yeah, the thing is, right now we have 'unsigned long' as the "wordsize". And I want to point out that that is not about "pointers" at all, it's about pretty much everything. It shows up in some very core places like system call interface etc, where "long" is in very real ways the expected register size. So the 128-bit problem is actually much larger than just "uintptr_t", and we have that "sizeof(long)" thing absolutely everywhere. In fact, you can see it very much in things like this: #if BITS_PER_LONG == 64 which you'll find all over as the "is this a 64-bit architecture". Out bitmaps and bit fields are also all about "long" - again, entirely unrelated to pointers. So I agree 100% that "we will have a problem with 128-bit words". > So how do you think we should solve the 128-bit-word-size problem? > Leave int at 32-bit, promote long to 128-bit and get the compiler to > add __int64 to give us a 64-bit type? That would likely be the least painful approach, but I'm not sure it's necessarily the right one. Maybe we might have to introduce a "word size" type. > The only reason I like size_t is that it's good _documentation_. > It says "This integer is a byte count of something that's in memory". > As opposed to being a count of sectors, blocks, pages, pointers or > turtles. Yes. And yes: > extern int bio_add_pc_page(struct request_queue *, struct bio *, struct page *, > unsigned int, unsigned int); We should use a lot more explicit types for flags in particular. Partly for documentation, partly for "we could type-check these". And in declarations it might be good to encourage use of (helpful) argument names, in case it really is just an offset or other integer where a type makes no sense. Linus