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 8AA44C433EF for ; Sat, 12 Feb 2022 01:06:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 82F086B0075; Fri, 11 Feb 2022 20:06:00 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7DF0B6B007B; Fri, 11 Feb 2022 20:06:00 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6CE4F6B007D; Fri, 11 Feb 2022 20:06:00 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0068.hostedemail.com [216.40.44.68]) by kanga.kvack.org (Postfix) with ESMTP id 5A4476B0075 for ; Fri, 11 Feb 2022 20:06:00 -0500 (EST) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 0E7648249980 for ; Sat, 12 Feb 2022 01:06:00 +0000 (UTC) X-FDA: 79132336080.11.5DE0F22 Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by imf30.hostedemail.com (Postfix) with ESMTP id D538E8000C for ; Sat, 12 Feb 2022 01:05:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1644627958; x=1676163958; h=date:from:to:cc:subject:message-id:mime-version; bh=H07qaKKnB1/Rwj0EaU6kOlwcsfqpK2vhuLy0FxKtZg0=; b=fIIkkJPnLhlCOk3VAehDpnvpGhrMdyzrvruv4EKxHxmiFs7sKZMt3ptO GFYavMqmRXboDp3SQee2+yDtdPLS7WwO7+vtnLzMo6/rbZInYVjzd2x9n 5XDsqOQlRDJbUkyETaUyMjFjiqJUM0Lq25hD77Oe/ZixUSxE958Ym6nZz OamllHtEdZnVQYdIGqP3H5RxtcnGllXtIkr5yy73jvhtysFQctJ+fOW52 jaozY0rAzLs/MnzLtyUClQ6asaxlcQuiWHhRWyRmWzho7gD/GfZY0zn46 SpQl7t9vwJ0rWiTbBdKDs62mGTV/YZIYqRrvwt2HfTHvtEtHhO3o7m08/ A==; X-IronPort-AV: E=McAfee;i="6200,9189,10255"; a="310575886" X-IronPort-AV: E=Sophos;i="5.88,361,1635231600"; d="scan'208";a="310575886" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Feb 2022 17:05:57 -0800 X-IronPort-AV: E=Sophos;i="5.88,361,1635231600"; d="scan'208";a="542308724" Received: from iweiny-desk2.sc.intel.com (HELO localhost) ([10.3.52.147]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Feb 2022 17:05:56 -0800 Date: Fri, 11 Feb 2022 17:05:56 -0800 From: Ira Weiny To: lsf-pc@lists.linux-foundation.org Cc: ira.weiny@intel.com, 'Dan Williams' , Dave Hansen , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: PKS for the page cache and beyond Message-ID: <20220212010556.GU785175@iweiny-DESK2.sc.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.11.1 (2018-12-01) X-Stat-Signature: d99hdbkppbqmyqcxuyyiximxii8gtor5 X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: D538E8000C Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=fIIkkJPn; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf30.hostedemail.com: domain of ira.weiny@intel.com has no SPF policy when checking 134.134.136.31) smtp.mailfrom=ira.weiny@intel.com X-Rspam-User: X-HE-Tag: 1644627958-389003 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: Hello, Protection Key Supervisor (PKS) presents a way to control access to a large domain of memory quickly, without a page table walk or TLB flush, as well as with finer granularity; allowing protection control on individual threads. Multiple areas of memory have been identified as candidates to be protected with PKS. These include the initial use case persistent memory (PMEM), page tables[1], kernel secret keys[2], and the page cache.[3] Like PMEM the page cache presents a significant surface area where stray writes, or other bugs, could corrupt data permanently. I would like to discuss the ramifications of being able to change memory permissions in this new way. While PKS has a lot to offer it does not come for free. One trade off is the loss of direct access via page_address() in !HIGHMEM builds. Already PMEM's faced challenges in the leverage of kmap/kunmap. While the page cache should be able to leverage this work, this is driving a redefinition of what kmap means. Especially since the HIGHMEM use case is increasingly meaningless on modern machines. Ira Weiny [1] https://lore.kernel.org/lkml/20210830235927.6443-2-rick.p.edgecombe@intel.com/ [2] https://lore.kernel.org/lkml/20201009201410.3209180-3-ira.weiny@intel.com/ [3] https://lwn.net/Articles/883352/