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 X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F0752C34026 for ; Tue, 18 Feb 2020 15:15:25 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A80E2207FD for ; Tue, 18 Feb 2020 15:15:25 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="BGGL+Ne8" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A80E2207FD Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 5438C6B0003; Tue, 18 Feb 2020 10:15:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4F5DA6B0006; Tue, 18 Feb 2020 10:15:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 40BD36B0007; Tue, 18 Feb 2020 10:15:25 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 25CD76B0003 for ; Tue, 18 Feb 2020 10:15:25 -0500 (EST) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id B98528248047 for ; Tue, 18 Feb 2020 15:15:24 +0000 (UTC) X-FDA: 76503596568.22.smile14_379184cbe724b Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin22.hostedemail.com (Postfix) with ESMTP id 6D3DE1802B9DF for ; Tue, 18 Feb 2020 15:06:22 +0000 (UTC) X-HE-Tag: smile14_379184cbe724b X-Filterd-Recvd-Size: 2546 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf19.hostedemail.com (Postfix) with ESMTP for ; Tue, 18 Feb 2020 15:06:21 +0000 (UTC) Received: from hump (unknown [109.236.136.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id BA6C62176D; Tue, 18 Feb 2020 15:06:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582038380; bh=Ix9S312+NOvLEVp2r0igrJQdIcR5Oq3txVksA1wy/lQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=BGGL+Ne85Byrg92nMhInoBRZw1cYTDpAvV6QhQ8PXAb6HouuvyJ+Z3dWTxXEh5fe8 iggl3+0FvBT07fvbWX2qW8mvSddoKXQovb2/3/dPA18n0688Gzo1V+5r/0IN4YQGLC S6PkurkfSx+dJFeSR6Q2pOWV0iVAyE6pWlcVZu7I= Date: Tue, 18 Feb 2020 16:06:15 +0100 From: Mike Rapoport To: "Kirill A. Shutemov" Cc: Mike Rapoport , lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org Subject: Re: [LSF/MM/BPF TOPIC] Restricted kernel address spaces Message-ID: <20200218150615.GA9478@hump> References: <20200206165900.GD17499@linux.ibm.com> <20200207173909.e5gtjys7q4ieh2fv@box> <20200211172047.GA24237@hump> <20200211215334.bftqnru57mv5bcza@box> <20200216063504.GA22092@hump.haifa.ibm.com> <20200217103457.c3bmwp43fpa3ho4f@box> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200217103457.c3bmwp43fpa3ho4f@box> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000868, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Feb 17, 2020 at 01:34:57PM +0300, Kirill A. Shutemov wrote: > On Sun, Feb 16, 2020 at 08:35:04AM +0200, Mike Rapoport wrote: > > > BTW, with clarified scope of the AMD Erratum, I believe we can implement > > > "collapse" for direct mapping. Willing to try? > > > > My initial plan was to use a pool of large pages to satisfy "secret" > > allocation requests. Whenever a new large page is allocated for that pool, > > it's removed from the direct map without being split into small pages and > > then when it would be reinstated back there would be no need to collapse > > it. > > It might be okay. But you likely will have to split 1G pages in direct > mapping into 2M. Right, it is quite likely, at least for the dynamic allocations. > Being able to repare the direct mapping is more generally > useful. And it's not strictly related to the "secret" memory. I'll try to have a look at it. > -- > Kirill A. Shutemov -- Sincerely yours, Mike.