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 7E3C9C43334 for ; Thu, 16 Jun 2022 16:13:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DE0A36B0071; Thu, 16 Jun 2022 12:13:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D8F0B6B0075; Thu, 16 Jun 2022 12:13:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C2FFF6B0078; Thu, 16 Jun 2022 12:13:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id B45C56B0071 for ; Thu, 16 Jun 2022 12:13:00 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 61CC1214A8 for ; Thu, 16 Jun 2022 16:13:00 +0000 (UTC) X-FDA: 79584592920.05.97F5CBA Received: from mail-ej1-f44.google.com (mail-ej1-f44.google.com [209.85.218.44]) by imf10.hostedemail.com (Postfix) with ESMTP id D3FA1C006C for ; Thu, 16 Jun 2022 16:12:58 +0000 (UTC) Received: by mail-ej1-f44.google.com with SMTP id hj18so3066713ejb.0 for ; Thu, 16 Jun 2022 09:12:58 -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=B7nG0bqPdDQFZmSsFMUEcSWlp2CbGSXVxl7p6eJduFo=; b=P53257MRq0PaCsnXR0yo3W9NK8xQW/61/UG/ASXpReWpNC4QQ4/sCTBKq1QbtQuXIc P4JQ95jDMrDVHrQSgnN6Kff9BQSy0ixclTE0nn0kcYQNSzYiY9ct4iZ57jyvEhCUWTLJ 2iQT2Qc5OTEnrylWq4IoFB8fqMPhD8qamKT0o= 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=B7nG0bqPdDQFZmSsFMUEcSWlp2CbGSXVxl7p6eJduFo=; b=ojepUPd0+bDrKDDysgyMQV2Vf+J4kawYFnFOoAVpVh9zDIBo/sIlHhz3W/Og6R+NHU O4Z7gtBAGpSjGLm1e1ruixRJfFNKHz2g7B6RgO7XO98YoYDomez9VXWqBL7O0Ifoj6Kl m+ohOaVeDA0DyHHZL53CUdGS76GGH2jkDY2tPqnF52mMQ61CSi21QkYfjme2fsMY1Zbh 5DGqmNoZKnp+8U3+ILWEGqy9Vx6hDhUxs16a3UUe2C4jljcNJXj2b8Kx8hM4F+4+WydO /nyBvog7BYpJIXj37xcEIy2WJsLhokVbjKGQw9TsXDnaXFP1a+7qGeNMLg5wMRxwL3Yn y/Yg== X-Gm-Message-State: AJIora/xjxENixl03bttBrEV9/qOFD5ZSt0ZpxPClPfegGBEhtddMyrN P9E5ePYoqokqFBbX3gaeawtE3Z4miT9xCR/dDCQ= X-Google-Smtp-Source: AGRyM1vbrIwvGUTGhhiS6fKuOM1sdVQo2wPZ3orJ04WEOu2HpG1scK6qnLNXgAHrdY1EuqdTwEemAQ== X-Received: by 2002:a17:906:5047:b0:710:456a:695e with SMTP id e7-20020a170906504700b00710456a695emr5143643ejk.433.1655395977013; Thu, 16 Jun 2022 09:12:57 -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 u3-20020a17090626c300b006fe9e717143sm923799ejc.94.2022.06.16.09.12.54 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Jun 2022 09:12:55 -0700 (PDT) Received: by mail-wr1-f45.google.com with SMTP id u8so2479766wrm.13 for ; Thu, 16 Jun 2022 09:12:54 -0700 (PDT) X-Received: by 2002:a05:6000:16c4:b0:20f:cd5d:4797 with SMTP id h4-20020a05600016c400b0020fcd5d4797mr5320732wrf.193.1655395974456; Thu, 16 Jun 2022 09:12:54 -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:12:37 -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-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=P53257MR; dmarc=none; spf=pass (imf10.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.218.44 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1655395978; 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=B7nG0bqPdDQFZmSsFMUEcSWlp2CbGSXVxl7p6eJduFo=; b=owEyw5cww6+kuxfPOy9oIE7t2Rxw6NF/Zs6nlRVAzEWSBl0jG1GtJUkpgFs0/uaZEWsYCc I3B6IKI7sXnf2ACJtuPyGvSagQhlX9jfdqy1OdGWVEHUk369gpL49xBWueQA2ycoH0BKqk tP2yEqrU7R0FWK/0b5UaZ22E2UWtglY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1655395978; a=rsa-sha256; cv=none; b=hH6wOcY0zfkX8SK6IPEjwcD8t7iwGDAnWZZzyyEU8f7GyhV7JP5OSRZLnHjuSJgEaE2HLY gnFOLPZI7W/KMfJSq0hJIv6VwfqOZ8ySmpVBDUBRWtlwYAyjIyQ/Pnk+SerJGX8cR7CSHu V2b4ICW+e+U4KfpDxtjiu9bn930MROA= X-Rspam-User: X-Stat-Signature: 9znxzdmgahowgy589w4io3yiix3ia14j X-Rspamd-Queue-Id: D3FA1C006C Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=P53257MR; dmarc=none; spf=pass (imf10.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.218.44 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org X-Rspamd-Server: rspam05 X-HE-Tag: 1655395978-706647 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:59 AM Linus Torvalds wrote: > > 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). Ok, so I wrote that just because that particular issue has happened before with other types. But then I actually grepped for uintptr_t use in the kernel. And guess what you find when you do that? You find #ifdef BINDER_IPC_32BIT typedef __u32 binder_size_t; typedef __u32 binder_uintptr_t; #else typedef __u64 binder_size_t; typedef __u64 binder_uintptr_t; #endif exactly because user space interfaces used this broken sh*t-for-brains traditional model that we've done over and over, and that has been a big mistake. We have similar mistakes in things like 'off_t', where we have a mishmash of different versions (off_t, loff_t, __kernel_loff_t, compat_loff_t) and several duplicate interfaces due to that. The drm people (who end up having had more of this kind of stuff than most) actually learnt their lesson, and made things be fixed-size. We've done that in some other places too. It turns out that "u64" is a fairly good type, but even *that* has caused problems, because we really should have had a special "naturally aligned" version of it so that you don't get the odd alignment issues (x86-32: 'u64' is 4-byte aligned. m68k: u64 is 2-byte aligned). So yeah. size_t and uintptr_t are both disasters in the kernel. size_t we just have to live with. But that doesn't mean we want to deal with uintptr_t. Another issue is that we can't always control where user space defines their types. Which is why we really don't want to use POSIX namespace types in any interfaces anyway. It turns out that "u8..u64" are great types, and adding two underscores to them for the uapi headers is simple and straightforward enough. Because using other types ends up being really nasty from a namespace and "core compiler header files declare them in compiler-specific places" etc. Sometimes they are literally hardcoded *inside* the compiler (size_t being that kind of type). Anyway, that's more of an explanation of why the whole "just use the standard types" is simply NOT a good argument at all. We end up often having to actively avoid them, and the ones we do use are very *very* core and traditional So the whole "just use the standard type" _sounds_ sane. But it really isn't, and has some real issues, and we actively avoid it for good reasons. Linus