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 F0F2CC43334 for ; Thu, 16 Jun 2022 16:44:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7827E6B0071; Thu, 16 Jun 2022 12:44:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 733586B0072; Thu, 16 Jun 2022 12:44:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5FA4A6B0074; Thu, 16 Jun 2022 12:44:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 499DD6B0071 for ; Thu, 16 Jun 2022 12:44:34 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay13.hostedemail.com (Postfix) with ESMTP id 1A476602A4 for ; Thu, 16 Jun 2022 16:44:34 +0000 (UTC) X-FDA: 79584672468.04.A6CF707 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf25.hostedemail.com (Postfix) with ESMTP id 8E07CA0093 for ; Thu, 16 Jun 2022 16:44:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=rdCg6im4FTYRC+krLkTNcrz9yXNDSAEOLtpVfWokJzk=; b=lIYqkylRNsFWHYC10t48L3rTzz yBq8yCuNVVYqjoqPFXIS46lBCHD2NlAezsgABwyHdfMw66+kZP182Ua/ep6vVGNTs4F4CopCrFbEw BWwqJURZ+2cthMYSs2sTja5FH6wt9G7AD7XNbVJa6piDo9PI9RUuHDlswpJ0uDp36s2PxE+EBlFod Ea/aw52v+C5EArkPseYDvvLUiGIaKYuhrvSLyidul12C5DII7ZZBPjIYY8bncKLacdtXhZJCZgYw4 YkddyDxUs+Bv8mvNdNch9eNcVV46iAs17/v9EfjT1Whiyq+JdK1E62ph6AEv4FwDeksedEJK6XfI+ e6jnqHCg==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1o1sba-0025gl-SZ; Thu, 16 Jun 2022 16:44:26 +0000 Date: Thu, 16 Jun 2022 17:44:26 +0100 From: Matthew Wilcox To: Linus Torvalds 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 Subject: Re: [PATCH] usercopy: use unsigned long instead of uintptr_t Message-ID: References: <20220616143617.449094-1-Jason@zx2c4.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1655397873; a=rsa-sha256; cv=none; b=8Bjk/by3nZJ8D5nxUKzfuNwh4RyRlHNy3E69E91/pGzUX1NfhPJKthVfKAKZXcs+qQ2vm/ /4UTyGBhte9ypktA3HAo5p0+ykAppeVUAVhuRyKnqlU+924M0HNbK9mvvvQO+gtJqCSCZK OcRzyLLzR3RF2PMYsuGC6raOMGEleWY= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1655397873; 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=rdCg6im4FTYRC+krLkTNcrz9yXNDSAEOLtpVfWokJzk=; b=YcQRC63E0pfxAypPKFjrlThc+tvnf1mxkAG6sMyxeIzNpaFyOWcslQ4XjZWeg/3qLFEiua 2eHAjpiQa5RWw7R1F+3Kxlvnf2sYwwMhpPiWuMX7GnjqxeKjAHoO9gXwTwtsjxY51v071t qeBdGl8Av7MdXOjkOnSAiDSpzVu2dwM= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=lIYqkylR; dmarc=none; spf=none (imf25.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=lIYqkylR; dmarc=none; spf=none (imf25.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 8E07CA0093 X-Stat-Signature: 9jakowx3reigothqt6hppk7se8c4mfq3 X-HE-Tag: 1655397872-147750 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 08:59:51AM -0700, Linus Torvalds wrote: > 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. I don't care about the odd historical cases either. > 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. 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. 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? > 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. 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. As an example: extern int bio_add_pc_page(struct request_queue *, struct bio *, struct page *, unsigned int, unsigned int); What the hell are those two ints? Based on experience, they're probably offset & length, but who even knows what order they're in. > 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"). Yes, ARM is just crazy here. We should get the compiler people to give us an option to make size_t unsigned long. Like we have -mcmodel=kernel on x86.