From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=202.12.124.147 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794473813; b=RoLeM8dJqhjyshQ8/tluN0YuqBhZflbOffPuFIwCHUivL39yyxVNvp2DPMIFE+/9TkV/ 1NAZjhqwjD8iL4paMzYD7Qro6B02rlH31W16vL3rv+zU5M5tqu7foqS6afJRJwZgwAL5d 3qmnzLMeiUN4aYGKemj1QU5xC0HFR+iwBSYGXcBSorYXCKhBkQRkK7hzlPs9v1NjYRvKz KCIIT4lxw0klzTldwJVqfYCkoyIyMxAusVIkDIuep2s0wuNak6/cpLaquVcROOAuMt9Jk Qlz466LNO32FrOI6wmNxe3p8ZjNbr2NCwTAAqB9Sp5jWpPKbpzXU/N1YAXFbUnzuScg== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794473813; h=DMARC-Filter:Received:Received:DKIM-Signature:DKIM-Signature: X-DKIM2-Info:DKIM2-Signature:X-DKIM2-Info:Message-Instance: X-ME-Sender:X-ME-Proxy-Cause:X-ME-Proxy:Feedback-ID:Received:X-Mailer: MIME-Version:X-ThreadId:Date:From:To:Cc:Message-Id:In-Reply-To: References:Subject:Content-Type:Content-Transfer-Encoding; bh=rEDyzDvctiKMCWHEwGxzSSTUsEjyrAP4XO5pemqaf/w=; b=K9wi/XNqZtmHlj3cgPPe52QeqW4np8G0LDIh0eeSl+U+r962BC+9X6qfbKyXolC0BO27 ExO5W0jaZmmVUfucu5RepGUD1uis+DSs+rAIAe61ig3k6O8aYL5xRxElm+tgdJ3DqhEGD fUkyEONJD2OF2popS45OL0clCD5tAHNkt8JrQccAYsti99AXBM1y5gdy4u+cZXZMXkPBC j6g5Gn7krkS54N9c2fZeTsR75w98hnG7fM1xXkrv5uvEWuUNB62H5AM3bPhd+JaOGo9Yr KO3aTwpb08PdwlZ9rmxFq5kFZ5e20r0KZWV/y0foKprnO7iCkWNdSrNnQUnKw5nhE7A== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=arndb.de; spf=pass smtp.mailfrom=arndb.de; dkim=pass header.d=arndb.de header.i=@arndb.de header.a=rsa-sha256 header.s=fm2 header.b=B3knZGFb; dkim=pass header.d=messagingengine.com header.i=@messagingengine.com header.a=rsa-sha256 header.s=fm3 header.b=1UQSHGCM; arc=none smtp.remote-ip=202.12.124.147 Received: from fout-b4-smtp.messagingengine.com (fout-b4-smtp.messagingengine.com [202.12.124.147]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3274860A2625 for ; Thu, 12 Nov 2026 08:56:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 3274860A2625 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arndb.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arndb.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=arndb.de header.i=@arndb.de header.a=rsa-sha256 header.s=fm2 header.b=B3knZGFb; dkim=pass (2048-bit key, unprotected) header.d=messagingengine.com header.i=@messagingengine.com header.a=rsa-sha256 header.s=fm3 header.b=1UQSHGCM Received: from ams-compute-02.internal (ams-compute-02.internal [10.64.2.62]) by mailfout.stl.internal (Postfix) with ESMTP id 67BED1D00245 for ; Thu, 12 Nov 2026 03:56:52 -0500 (EST) Received: from ams-imap-03 ([10.64.2.23]) by ams-compute-02.internal (MEProxy); Thu, 12 Nov 2026 03:56:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arndb.de; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1794473793; x=1794560193; bh=rEDyzDvctiKMCWHEwGxzSSTUsEjyrAP4XO5pemqaf/w=; b= B3knZGFbJoyqxhvAjg5ey4pgvXQ0+dX+2yrqxypUpfmLl52FvtNsp7+AX8SbQ/eD QB4o9/31f8xFXCXe56hraiMz96Up0KKZvOb2Y5C65VShVM0pPaDafBjDrSUg42VY tu9bgejyvmqkt1Sc9Y32autzBDXmungVYOYMmKlWzY8ke9h7yX3aXbw7wQqSIKs3 owqqHduQlPeKvwCMeJG/2LJco0+TSA+EyuE40Mo+9A/AlkXjnBpb4ObaqIe0Doxc 7R11bWCv4vRYIh1QpCl5N1NsJgYyvfBQVk0IZtDm5jfVeuHETVudImiaPHrGdr9O vc7/hsrU2ooBu9I+vxQIQA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1794473793; x= 1794560193; bh=rEDyzDvctiKMCWHEwGxzSSTUsEjyrAP4XO5pemqaf/w=; b=1 UQSHGCMZ2A3z8bSIkkWxeq6RnxTXCPrxpPWHAyytgP+bJFnjHFjyYHqv4hm0qCHi QYj5WIQxDSWITpVoqdkvKqOQ6WfVb701r08hcNQLu5c31R4jKN1xLVhnaNofI2HX 7FdlCq7ohwLhQBbrPhAF/DBKK326jQC/kxRtegHB3eLgHLY3PWtxVOOFT5sBaYxH iEXrIpL7ps7Vq4atKdHaQMjAWH1A1hydNB2gIjGap0JgIebeP6f+c/OshDqYw/Jr vUJZRxhTpwPPzneK6Bk38wsyBQPOmtYPcLegI1AUZjxz+ntB7H/oAx/pXKxLSRwD hopHAfS59cof80uyciXMg== X-DKIM2-Info: draft=ietf-dkim-dkim2-spec-09; repo=github.com/dkim2wg/interop; date=2026-11-03; sw=lmtpprox; action=sign d=arndb.de a=rsa-sha256; DKIM2-Signature: i=1; m=1; t=1794473793; d=arndb.de; mf=PGFybmRAYXJuZGIuZGU+; rt=PGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc+; s=fm2:rsa-sha256:hxoOpuyRcfoT+OHXXUW1Qfz49E+f2yxp7t0yXFPb3D/fcn3 fHvt6AoHOsIYFB7OqoYjvCMAabuFZUMDYuxmFW+YNrDSNgfIp2tcCR4TgA/q3Q/k S/wmoFGpXn9dj+2m3/BTOGkoSRUC9ELftJil+5eEV5WGkyqkbQQBowN1mfzWgJKu Jt29q1eC0nbWazAB9y8p2aZfqtW5q0YrDqDIvJ3sQ2zqClQSqfpVi6HaZsm2QRG7 ekZ0Ku9mwLJXqlQjxW/BZG3mfbiNqlGSr21loSLzjoKrkZt12EGVxpt7L/EsvJ5v BXk9yy5pvGII7k5WjC+SuwC/Ksdi8IsP+nZ06fg==; X-DKIM2-Info: draft=ietf-dkim-dkim2-spec-09; repo=github.com/dkim2wg/interop; date=2026-11-03; sw=lmtpprox; action=mi-m=1; hc=12; hn=cc,content-transfer-encoding,content-type,date,feedback-id, from,in-reply-to,message-id,mime-version,references,subject,to; Message-Instance: m=1; h=sha256:bxT2HtsddpIKccxw7D1EmmeuIKfYJp+MJ2nSGobHrHU=:sEmA3MCn6JLrIUaQkRNBmsF7Hz02Y0iwntBVDLMI0ZY=; X-ME-Sender: X-ME-Proxy-Cause: dmFkZTE3ND7a5+W1Z07eormEvJEB+XP9yRNxmJWlhqo4nFZBM2kAyJQF7ZgJlr2V+yFcEa l9MRmavypBJJ+1A3waVwnEHhrM4U0pZpCmMYKIXvfnZkXMGbKdecZtrxLKkn6LEq19o5fE gPq8WxneDUi3v4xiFBdFxJqhhRjF9l4qFHfKxbM/8/kEKMzoow8MOCqc8EgLK/YGye/NOx vJ+BeW0pJ1MEvAjPtKHXRRQgaz1GtmTJKeuhP2oScGxUjAxi6NvtA3CvTfeHnIQJVEo9ZV dg2D6P1vG5wAmVpHBLy1jTDsA3jHwbynxf2/c8p8S1vmmHEGJ6xAPZTTV5Umrrj1UI3Khs rJijqRdX01D2IUPunT3qBzgERFBVZ8jYBYw1H3yAWZItZ9j4airbtb5XjMvlG++YM1xjMj nmYen9siqd5jtfWF+5rxuSCWu//0CHbbjZOuheK/lwuiWNnUidGYUvyWOFd9E2OfMRQyJo NHUJLrgFmF/YLzCIRd6QgoB46bEjyL4va2ECLKod74mkfUM9Bt3nKjoMZsBw6FKGE9i6pb kcdlCi+42mrcvNt9/oRYrgd7nZbADhLRxQvbPjTXfqJ8XvHIJ7OuVZ6HyNF9xugO4WyMQv IHitba4dtlHe8UFBYfWm9s4Tizbuv07yoIS03Wj6UhMEjI5BgOKm5i1NzONA X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.ams.internal (Postfix, from userid 501) id 1A43C32A0099; Thu, 12 Nov 2026 03:56:20 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 X-ThreadId: AD8wiEBgakfZ Date: Thu, 12 Nov 2026 09:55:48 +0100 From: "Arnd Bergmann" To: "Linus Torvalds" , "Christian Brauner" Cc: "Matthew Wilcox" , "Kirill A. Shutemov" , "Alexander Viro" , "Miklos Szeredi" , "Amit Shah" , "Jan Kara" , "David Hildenbrand (Red Hat)" , "Zi Yan" , "Bernd Schubert" , "Hugh Dickins" , "Baolin Wang" , "Andrew Morton" , "Greg Kroah-Hartman" , "David S . Miller" , "Eric Dumazet" , "Jakub Kicinski" , "Paolo Abeni" , "Simon Horman" , linux-fsdevel@vger.kernel.org, fuse-devel@lists.linux.dev, virtualization@lists.linux.dev, Netdev , linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@meta.com, "Malin Jonsson" , "Richard Weinberger" , "Geert Uytterhoeven" , "Nishanth Menon" , "Frank Li" Message-Id: In-Reply-To: References: <20261110145241.536019-1-kas@kernel.org> <20261110145241.536019-2-kas@kernel.org> <20261111-heimreisen-ungeziefer-empfunden-a892571f2c07@brauner> <20261111-thunfisch-wirbt-waldrand-822275b2d3b1@brauner> <20261111-stumpf-montag-miterleben-c4e2feac8090@brauner> Subject: Re: [PATCH 1/4] virtio_console: copy pipe buffers in splice_write() Content-Type: text/plain Content-Transfer-Encoding: 7bit On Wed, Nov 11, 2026, at 20:26, Linus Torvalds wrote: > On Wed, 11 Nov 2026 at 10:53, Christian Brauner wrote: >> >> If that's the official new stance than I'm very happy. > > I definitely want to remove HIGHMEM entirely in the not too distant > future. And before we remove it, we can most definitely document the > fact that we will not be worried about insane users. > > And things like security issues count as "insane user": if you use > HIGHMEM outside of controlled embedded setups or museum pieces you get > to keep both pieces when it breaks. > > IOW, it's legacy. We should aim to not introduce *new* bugs to it, but > if there are pre-existing bugs they very much count as "don't care", > this will be removed soon. Agreed. There is also the option of adding Kconfig dependencies to mark things that are known broken with highmem when we either know that it is buggy, or we have a good reason to break something that none of those remaining users should be using. > I think the only reason it wasn't removed a couple of years ago > already is basically a few old 32-bit ARM platforms that still used > it. > > Those platforms still exist, and I predict that they'll still exist > next year, but if those users have to stay at the current LTS kernel, > that's fine. I tried to push for what I thought was an aggressive timeline last year, but that would still keep the Arm bits for a couple more LTS releases and only gradually reduce the scope of highmem in the meantime, removing support from architectures, file systems, and drivers where possible. See https://lwn.net/Articles/1051010/ for a summary of my talk in Tokyo, including the slides and a link to the video for anyone wanting more details. I also prepared a number of patches towards this, but have so far not been great at following up to get them merged, sorry about that. I definitely still want to revisit this soon, in particular the bits about defaulting to VMSPLIT_2G_OPT, and probably my patch to allow having (limited) discontiguous lowmem on Arm systems with a large MMIO hole. Scope-wise I think we absolutely need zsmalloc (zram/zswap) on arm32 to work with GFP_HIGHUSER, but enough people have told me that they still expect to need anonymous memory and ext4 page cache for a while, and probably powerpc32. The majority of __GFP_HIGHMEM allocations can probably just be converted to use lowmem, which would eliminate a good chunk of kmap() calls as well. In my attempts to do that, I came across two problems I'd have to solve though: - Movable allocations (GFP_HIGHUSER_MOVABLE) imply highmem. while I think only 64-bit architectures support movable pages today, we cannot currently express an allocation that should be movable on 64-bit but lowmem on 32-bit. - Internal users of tmpfs (in particular DRM/GEM) usually don't want highmem or movable pages, but actual tmpfs does default to GFP_HIGHUSER_MOVABLE. Separating the two is complicated. I added a few people to Cc here that I believe care about having several more LTS releases with some highmem support because of existing customer requirements. Arnd