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 B0139C54EBD for ; Fri, 6 Jan 2023 21:43:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1FE268E0002; Fri, 6 Jan 2023 16:43:22 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1ADB98E0001; Fri, 6 Jan 2023 16:43:22 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 09D848E0002; Fri, 6 Jan 2023 16:43:22 -0500 (EST) 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 EE6BF8E0001 for ; Fri, 6 Jan 2023 16:43:21 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id CA7E3AAAF2 for ; Fri, 6 Jan 2023 21:43:21 +0000 (UTC) X-FDA: 80325700602.24.52BE695 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf08.hostedemail.com (Postfix) with ESMTP id D8AF016000E for ; Fri, 6 Jan 2023 21:43:18 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=j0bkeeFM; spf=none (imf08.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1673041399; a=rsa-sha256; cv=none; b=ZjZiEXvwmKmDUAgbciVA/6cnhajxTIe9HBdH2rN0cALgGItmtrhmrGDNHlviacdQaNU6QM AxTplEXRhcFMV/gfqsYvP+pH97pcTGkOI0r6fUTOXZ8GlwvsHcV4nCOVIyLLR0qizWtAyZ 1fhhYLZwKUFRIJW97AVQaSFSAtmQQys= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=j0bkeeFM; spf=none (imf08.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1673041399; 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=JIVcLmmyA6/m+YiOwB7DFkkX+oWdAkbzFPPqwaVy8WY=; b=YFE7RkmrtQAuCyevWffpA20Ol9ObFNbYM0mm0rqKbPRTaYPExdyAxuy4EW6P7IEHKdJKt+ hGpWUcDI7MsB4/RhRHICgWzdadXWanXlTQ0mZN38FY4hkUc+2I8g9P3RiNuoD9eN1u4uce JXVa0npPBgE0mbUb2NUThdrh4gZoIGI= 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=JIVcLmmyA6/m+YiOwB7DFkkX+oWdAkbzFPPqwaVy8WY=; b=j0bkeeFMEsRakLw1tzZ97Qcjr2 fMJY7Fxe4ZF7tc0SURp8dpL2Ow9Uu2YBygIcZIxjQeB5m7w8GE8zW7QCBrNV179lXrtQaP4ePRATi 1TJEzTkljdgsz7FUDMDF8WjfnVP361xy6iaMRxYmy+b829Fh7lzodyMlv8pM4Mk5DXxt93EjvnyFV KIezkNoLiLhVhGAQxFxwjvToJb7GqXE1tIBWKlUlEA/Tq6IUNO+LukGPZkpOQCDL2gV0VQogwW6Nk NUIsOqd7JzRCX2Hu433a4Ym6WbpYd69/uwECIk+3wbLNWNr5B/keRf1ZTC6K13p0SxqIWl4sUhbDu 3VpY5E5g==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1pDuUC-00HWiP-0T; Fri, 06 Jan 2023 21:42:48 +0000 Date: Fri, 6 Jan 2023 21:42:47 +0000 From: Matthew Wilcox To: Linus Torvalds Cc: "Jason A. Donenfeld" , Yann Droneaud , Andy Lutomirski , Ingo Molnar , linux-kernel@vger.kernel.org, patches@lists.linux.dev, tglx@linutronix.de, linux-crypto@vger.kernel.org, linux-api@vger.kernel.org, x86@kernel.org, Greg Kroah-Hartman , Adhemerval Zanella Netto , Carlos O'Donell , Florian Weimer , Arnd Bergmann , Jann Horn , Christian Brauner , linux-mm@kvack.org Subject: Re: [PATCH v14 2/7] mm: add VM_DROPPABLE for designating always lazily freeable mappings Message-ID: References: <10302240-51ec-0854-2c86-16752d67a9be@opteya.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Queue-Id: D8AF016000E X-Rspamd-Server: rspam01 X-Stat-Signature: 76niofw6rsqbxi3mdf5xg4xpghhnx68u X-HE-Tag: 1673041398-625520 X-HE-Meta: U2FsdGVkX1+jEQJURXn2IC1v3ZhUlW6qns9YmFgk0ni4UIUGtrfM1naYPeGMUD2JZXKhUn7Z1iKAq2VOMVwZXLUdNhgnYF28LyLfD3sq0RDJEwZvSnT1iCMzNBE3BeVXsg31JOZYjAJE+SwMHGOgGWbSTN6U3XL5fCBS0NTq31KAC7G8xaQj9Z0tbJQGNyYMSdBd/lKrokaEGDNW5/SgqbJ2uPKUnBb04pQTZ68sYgzqbdqA1KmGcli4v3fq5aZckahB99nrIhk5X7qBYoUSBQo8Xfu8phz9j886LfmXwcWYOWL3T6H5wBavS5hxcLKUCP86TKORVXMa+P0jwp7qCooGND/acEg/AggixAl9C0IAh5gfvdiv9SdQEPxzVsTFPdfAsaH4NppTC/qtAQ/+KOxlHRTf+C3BEtihWLnP6DHC5n6yeyw2Qvnjk6BagpHR3CbrgT68usdKeSzg0tj0LCkohllgqX733G0lU62A+1cYW75M+FIE0Q51ypm2x7WNGhLqSq+Lv/ato4PwlkB2fQBZnW486Ws+lwU6bCDH6EynwgLBgZuU9pejt0KPInI/pUT2z3encefdG8LiMPms38PweTqOQ6gYSZpV8sYIPb4JfV3Q/e3iX6YAxoISqhFyxTR/xEgHBjDRFy337/4i9Ma9S71ClK89XpKkxKN7s7fYgvfBwWjWa4icO9wEwaACw5zdFrU67gpJR49i+AMVX33FOk/n1Q0K+H9A6fpc6veJYRg4EoGVzz6hNyIHbeMUVZx5c2XKmA7t9u94Gk1fGdEIcuFSibcpGrvoIUCw7EVaMRWHHSAPzV6YW0JsnSmwO7ZXDLE/Q0b9M8QBJN4QSIK3pgh4x0vHmN7ircLYdHEdgqOkwckbBH7W+9w7puMjMGqIJR12zy04Oky48uY7TA== 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, Jan 05, 2023 at 06:08:28PM -0800, Linus Torvalds wrote: > Side note: making the 32-bit issue go away is likely trivial. We can > make 'vm_flags' be 64-bit, and a patch for that has been floating > around for over a decade: > > https://lore.kernel.org/all/20110412151116.B50D.A69D9226@jp.fujitsu.com/ > > but there was enough push-back on that patch that I didn't want to > take it, and some of the arguments for it were not that convincing (at > the time). > > But see commit ca16d140af91 ("mm: don't access vm_flags as 'int'"), > which happened as a result, and which I (obviously very naively) > believed would be a way to get the conversion to happen in a more > controlled manner. Sadly, it never actually took off, and we have very > few "vm_flags_t" users in the kernel, and a lot of "unsigned long > flags". We even started out with a "__nocast" annotation to try to > make sparse trigger on people who didn't use vm_flags_t properly. That > was removed due to it just never happening. > > But converting things to vm_flags_t with a coccinelle script > (hand-wave: look for variables of of "unsigned long" that use the > VM_xyz constants), and then just making vm_flags_t be a "u64" instead > sounds like a way forward. I'd be more inclined to do: typedef unsigned int vm_flags_t[2]; and deal with all the fallout. That'll find all the problems (although leave us vulnerable to people forgetting which half of the flags they want to be looking at). Hm. We never actually converted vma->vm_flags to be vm_flags_t. Only vm_region, which aiui is only used on nommu.