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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B174EC00140 for ; Mon, 15 Aug 2022 08:27:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231575AbiHOI1N (ORCPT ); Mon, 15 Aug 2022 04:27:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52056 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231459AbiHOI1L (ORCPT ); Mon, 15 Aug 2022 04:27:11 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 367811F2D6; Mon, 15 Aug 2022 01:27:10 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id C7A30B80D2E; Mon, 15 Aug 2022 08:27:08 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 03A20C433C1; Mon, 15 Aug 2022 08:27:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1660552027; bh=dBIx+PmLRGvc7cD7WDIJNr/ZMKAAJrp3rOtO9O0twBI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Fi6obagsa2VeTXjLLIkaCsW5yRfB0dHm61ajgGCipzZARpg3l90eaEMX0cGslJ79l mJMpU5uT84gMrJt+KuVbtv7eJIV3R5O6xflo/vqXPLfnsLyk6mj/GHZ3rqE1tooSvF S8DlsKeavkLpv+SOwn8GL6w//e+k89GWaFE2rqL9t2RxBjMlYC4DMBaCVpudjWeuHI OJPNnVlIgk/RxGSjBU3T6iYsPmcqSNepyJFM0qV/QS+K3D3fCwayRylLlNY4BPN78n je+A3yJepZ69Bua/u39oqFlNqnlX7MfJyDgyrUnPlswU7Fxp/30fpuOjU4niXEcQCe wCn0EpJooHG1g== Date: Mon, 15 Aug 2022 11:26:51 +0300 From: Mike Rapoport To: Linus Torvalds Cc: "Kirill A. Shutemov" , Al Viro , Peter Zijlstra , Nathan Chancellor , Nick Desaulniers , Jeff Layton , Ilya Dryomov , ceph-devel@vger.kernel.org, Linux Kernel Mailing List , Matthew Wilcox , clang-built-linux , Dave Hansen Subject: Re: Simplify load_unaligned_zeropad() (was Re: [GIT PULL] Ceph updates for 5.20-rc1) Message-ID: References: <20220814225415.n546anzvud6sumux@box.shutemov.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Aug 14, 2022 at 08:43:09PM -0700, Linus Torvalds wrote: > On Sun, Aug 14, 2022 at 3:59 PM Linus Torvalds > wrote: > > > > If TDX has problems with it, then TDX needs to be fixed. And it's > > simple enough - just make sure you have a guard page between any > > kernel RAM mapping and whatever odd crazy page. > > .. thinking about this more, I thought we had already done that in the > memory initialization code - ie make sure that we always leave a gap > between any page we mark and any IO memory after it. > > But it's possible that I'm confused with the IO window allocation > code, which does the reverse (ie actively try to avoid starting > allocations close to the end-of-RAM because there is often > undocumented stolen memory there) > > I'd much rather lose one page from the page allocator at the end of a > RAM region than lose the ability to do string word operations. > > Of course, it's also entirely possible that even if my memory about us > already trying to do that is right (which it might not be), we might > also have lost that whole thing over time, since we've had a lot of > updates to the bootmem/memblock setup. We don't create gaps in the memory initialization code, everything that's E820_TYPE_RAM goes in the end to the page allocator with exception of partial pages. And this didn't change in the last few years. > Linus -- Sincerely yours, Mike.