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 54592C433EF for ; Thu, 16 Jun 2022 16:00:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E29406B0072; Thu, 16 Jun 2022 12:00:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DD9306B0074; Thu, 16 Jun 2022 12:00:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CA0CC6B0075; Thu, 16 Jun 2022 12:00:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id B97C06B0072 for ; Thu, 16 Jun 2022 12:00:12 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 8B75A33D86 for ; Thu, 16 Jun 2022 16:00:12 +0000 (UTC) X-FDA: 79584560664.18.EF84444 Received: from mail-ej1-f44.google.com (mail-ej1-f44.google.com [209.85.218.44]) by imf05.hostedemail.com (Postfix) with ESMTP id A5C4A100090 for ; Thu, 16 Jun 2022 16:00:11 +0000 (UTC) Received: by mail-ej1-f44.google.com with SMTP id n10so3629236ejk.5 for ; Thu, 16 Jun 2022 09:00:11 -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=BJ2jAaiEzLNQ93crLBAe3sDvH4iCO/x2lZ+zRlgdV/4=; b=cxj6vejdZIrdWg7i57fno7dIoPvsbKilzHyEXWvFkAoBv9r+QoFdy7bpOwZp2Ylk3B pfE/wp7Kfj88bh8j/WDUFirzzoX10qWcVrp+aqFo0r03zBUiPzkWhr4H7OcxpoTJRrbK rSMSCgfc1ly2bqQk3lU50OAV7bXFWH86uHjt0= 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=BJ2jAaiEzLNQ93crLBAe3sDvH4iCO/x2lZ+zRlgdV/4=; b=Mz1DcuMsbHFXhLoTghMssLq1PpfUcCxWZux1BvlezFQdQLuY1dirjpTPHqvLE8Hj73 2p0200En7IP1Mu5IeP2oiHXDYxuTtcajLpm0ObhXiy8REg9paIiP8N4uBWYqqSxYMwe5 h4wbsRRFwwwKlKICQDPA6K1b23PoOoG1pcO7CjTb4nNrFn6mgkcwUAuB12yLO8PnMEXR r3isRADro4gaPivnBVyGkgf0faBk3hPf+YNef0hvRDFPk7fOlveoTMzEMW2N/3bBQBnK 7Y8lVAyquUgmKpt95wdgRiGndqN79pEpd7ItoZnIrCjJ7bK77rIAIg5QRih2HuAjqUgG d1tw== X-Gm-Message-State: AJIora8hoQPl6WuHt8wuUm0KZMmHr5nuF5S+2unne8yu1yksvrROG1PD gODie8ClidTFIu0s/2rlYmpngMCVLc8GRvwtoNM= X-Google-Smtp-Source: AGRyM1vFNNYJR6z1B9E1VBvNUmkmiGdLlifvlNNL51PCWsMS6Mv8PQbZjj1XWe92WBUw+k5i2aT0cg== X-Received: by 2002:a17:907:2d0c:b0:711:e835:f80c with SMTP id gs12-20020a1709072d0c00b00711e835f80cmr5080899ejc.257.1655395209890; Thu, 16 Jun 2022 09:00:09 -0700 (PDT) Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com. [209.85.221.54]) by smtp.gmail.com with ESMTPSA id ee15-20020a056402290f00b0042dd3bf1403sm1987250edb.54.2022.06.16.09.00.08 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Jun 2022 09:00:08 -0700 (PDT) Received: by mail-wr1-f54.google.com with SMTP id x17so2447809wrg.6 for ; Thu, 16 Jun 2022 09:00:08 -0700 (PDT) X-Received: by 2002:a5d:47aa:0:b0:218:5ac8:f3a8 with SMTP id 10-20020a5d47aa000000b002185ac8f3a8mr5432558wrb.442.1655395207618; Thu, 16 Jun 2022 09:00:07 -0700 (PDT) MIME-Version: 1.0 References: <20220616143617.449094-1-Jason@zx2c4.com> In-Reply-To: From: Linus Torvalds Date: Thu, 16 Jun 2022 08:59:51 -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=1655395211; a=rsa-sha256; cv=none; b=nHmp6RQJycv1Na/XkYYgXbhUStWX8jhsipg+AdyB6NM8Yatqa84orxlScYoEZTLsaC6dbu fFmlycdzr9TS56nhDy16Jjvagfr3fdr+W7NvYSej8NGSFy0SnzcuaEvb4/dIRy+i1wFDmg KDpFZ8zULQFqzLfZk468tUvgMxtnwjA= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1655395211; 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=BJ2jAaiEzLNQ93crLBAe3sDvH4iCO/x2lZ+zRlgdV/4=; b=h3K0iTI/j36HvXaPpktlW7AXjti4qzQuRmysry8EDNJ4P5JBlYEhe171sg/DxTgfRuJWGc h60Ao9L2hV7R+OaU2hxVLnVJBE7a7p7tI5vbv4MoaeCbLWPG5pzH8J/CCa6vHfK+l9bV5t O21ECDqL9jWsfXjRjKrcv4Bp8+FjX9Y= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=cxj6vejd; dmarc=none; spf=pass (imf05.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.218.44 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=cxj6vejd; dmarc=none; spf=pass (imf05.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.218.44 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: A5C4A100090 X-Stat-Signature: zc1hij36s9m16strhgndk4x469cgqpg3 X-HE-Tag: 1655395211-306988 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 8:21 AM Matthew Wilcox wrote: > > I don't know why people call uintptr_t a "userspace type". It's a type > invented by C99 that is an integer type large enough to hold a pointer. > Which is exactly what we want here. On the other hand, "unsigned long" has existed since the first version of C, and is an integer type large enough to hold a pointer. Which is exactly what we want here, and what we use everywhere else too. The whole "uintptr_t handles the historical odd cases with pointers that are smaller than a 'long'" is entirely irrelevant, since those odd cases are just not a factor. And the "pointers are _larger_ than a 'long'" case is similarly irrelevant, since we very much want to use arithmetic on these things, and they are 'long' later. They aren't used as pointers, they are used as integer indexes into the virtual address space that we do odd operations on. Honestly, even if you believe in the 128-bit pointer thing, changing one cast in one random place to be different from everything else is *not* productive. We're never going to do some "let's slowly migrate from one to the other". And honestly, we're never going to do that using "uintptr_t" anyway, since it would be based on a kernel config variable and be a very specific type, and would need to be type-safe for any sane conversion. IOW, in a hypothetical word where the address size is larger than the word-size, it would have to be something like out "pte_t", which is basically wrapped in a struct so that C implicit type conversion doesn't bite you in the arse. So no. There is ABSOLUTELY ZERO reason to ever use 'uintptr_t' in the kernel. It's wrong. It's wrong *even* for actual user space interfaces where user space might use 'uintptr_t', because those need to be specific kernel types so that we control them (think for compat reasons etc). We use the user-space types in a few places, and they have caused problems, but at least they are really traditional and the compiler actually enforces them for some really standard functions. I'm looking at 'size_t' in particular, which caused problems exactly because it's a type that is strictly speaking not under our control. 'size_t' is actually a great example of why 'uintptr_t' is a horrid thing. It's effectively a integer type that is large enough to hold a pointer difference. On unsegmented architectures, that ends up being a type large enough to hold a pointer. Sound familiar? And does it sound familiar how on some architectures it's "unsigned int", and on others it is "unsigned long"? It's very annoying, and it's been annoying over the years. The latest annoyance was literally less than a week ago in 1c27f1fc1549 ("iov_iter: fix build issue due to possible type mis-match"). Again, "unsigned long" is superior. And the only reason to migrate away from it is because you want something *type-safe*, which uintptr_t very much is not. As exemplified by size_t, it's the opposite of type-safe. It's actively likely to be type-confused. Linus