Received: by 10.213.65.68 with SMTP id h4csp1483089imn; Thu, 29 Mar 2018 05:39:16 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+jtS1nGYap+y28kLsbhwdZCZB8FK+4vw0HcbIzJmFO0if4XtFBVJBPC/calCrE/0uirnnf X-Received: by 2002:a17:902:5acf:: with SMTP id g15-v6mr8032283plm.138.1522327156824; Thu, 29 Mar 2018 05:39:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522327156; cv=none; d=google.com; s=arc-20160816; b=WXZ0wiW9/zEKKxjw+PPoYJExADTKC9Xz+otbSvf/kiDDnMmWTLzitz5iN51Ro5G04q ZtouT2i01fbz5yQp2cXV0NBe/O1zQ1D2S6nJ+KLjGlSACnWI0EJ4OnL6HnfpsEWuR6+/ od5TyIGJiHUx5g17e4uG4VcDYo51TDbqaeLm881PRJBQ4KfCbfiZ15M8baRKmtrqgUS3 9fUQnEUOVg2qKmzMrxi7ZGtu4Qu3Hi5F+8RGEqA7YnbjNyHcp9fOyIOuFHapFzpJJImw Cul192FexfGiPFztETTjkMh6NXtHP6fOqROfEfQXzydwX9gy4JZbRk5AizpxEoIsGa80 V+wA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=r2CdKEET6IPbUKT6c3St6Ell4sG4mIC73OH92NTz/eA=; b=xzQC9Hpul037ugQ5aZTHL5Vw5Gfk9RaJnGO4GOHVJoYklvforFi9bYt/Lv9wC6B4jv SjCzwF6vvduY5zWV4eZcrg91uEfeg3+kTC19DUAEI3M5KYuEwLjfm/Pdx5v5S4PGC4Ph +h/LsBJQw0jnwYCVe/HL/xC1eiJfmXWvWw1/cxL8g1rxg5BNsiEYW8zo1ObmND5suTAl Dk5BUPjMf3lm47powpqyTiM+zmvhVsWefvVC1qPcrWcelkD5DxBOOR5/oU29vbHpC253 ZiMoBgIkK41WZ2jcymdt+PQK4oALUeAAmjRptAngdG3GLRnGNjmU9rly5cejbhgwv/Cc pduA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@shutemov-name.20150623.gappssmtp.com header.s=20150623 header.b=Nqc9aIAD; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d4-v6si6012254pln.721.2018.03.29.05.39.02; Thu, 29 Mar 2018 05:39:16 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@shutemov-name.20150623.gappssmtp.com header.s=20150623 header.b=Nqc9aIAD; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752489AbeC2Mhu (ORCPT + 99 others); Thu, 29 Mar 2018 08:37:50 -0400 Received: from mail-wm0-f45.google.com ([74.125.82.45]:39264 "EHLO mail-wm0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751182AbeC2Mht (ORCPT ); Thu, 29 Mar 2018 08:37:49 -0400 Received: by mail-wm0-f45.google.com with SMTP id f125so11285306wme.4 for ; Thu, 29 Mar 2018 05:37:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shutemov-name.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=r2CdKEET6IPbUKT6c3St6Ell4sG4mIC73OH92NTz/eA=; b=Nqc9aIADcQJ2pW/51ptXP2nrpAKefTd4CEL2e9oqKeLCTXv+dPl2d2J20uiJBOvpF3 q0zOhJgti+CdfzoUYavO8Ui57X+Q25ly/7Ojntgq9cfAQVcFgoXuZuGoKIDYKPXIx4vU oJCQurHulb7G8OIeB9gkWs2AxAMr8VPIeCMMCg0FW1xTNa+PzVf+O/nqctJ/ndeIFo7t IQEr3NMmkXNnSloxWFogLxSezKfIpqp1dcnVNOsWnTBsp+2C5THOiKDl5aU/a677oUaM o5zVeJiK6l5gkW9tQDH3jKOt+GGfhJrxD0VjJ+XRMFdPmJ7heoGz1m9YbZZKD5LL8ruD 5skg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=r2CdKEET6IPbUKT6c3St6Ell4sG4mIC73OH92NTz/eA=; b=Z7D2V3nAeq7ijmyI76R3Xsuo27V051jJnqk4PzIsm9HZmYdwEQVXvkjALo3QOh/n5B o2T2AFhe8m0wM4/np0zfUH9c1qAxRxZyvWXtk1nzdg5E1iP288Uww5tWVV/xHabiLbKs yzodDke0QvsTc1xi1wUeSihYXra9VOEE5Aw8sHvbpc6YKaSC23h4DJgveGl0NSPj7czK cQlF8TX5XbwBpu5C/2S6LY4PLELCOP84dAznSZlyWZ/Wro3Bgxa4EzZQWEXnbSH3kYZ5 N9bNHWV5O4clwZVv89u6sq73/SRgJIauTGVyPtHRFt826izPVIwWJJ/mv1VXOPJjyPVb p6lA== X-Gm-Message-State: AElRT7EXMdXFUhk51cetV9RwdTgywmkzTNKxfaweMxTrK8xCOnyZp30V BX/wltilBv4JPGFxK1o5O46uxg== X-Received: by 10.80.167.98 with SMTP id h89mr7385688edc.275.1522327068359; Thu, 29 Mar 2018 05:37:48 -0700 (PDT) Received: from node.shutemov.name ([178.124.220.81]) by smtp.gmail.com with ESMTPSA id r6sm4044581edi.21.2018.03.29.05.37.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Mar 2018 05:37:47 -0700 (PDT) Received: by node.shutemov.name (Postfix, from userid 1000) id 21D20648D520; Thu, 29 Mar 2018 15:37:12 +0300 (+03) Date: Thu, 29 Mar 2018 15:37:12 +0300 From: "Kirill A. Shutemov" To: Michal Hocko Cc: "Kirill A. Shutemov" , Ingo Molnar , x86@kernel.org, Thomas Gleixner , "H. Peter Anvin" , Tom Lendacky , Dave Hansen , Kai Huang , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCHv2 06/14] mm/page_alloc: Propagate encryption KeyID through page allocator Message-ID: <20180329123712.zlo6qmstj3zm5v27@node.shutemov.name> References: <20180328165540.648-1-kirill.shutemov@linux.intel.com> <20180328165540.648-7-kirill.shutemov@linux.intel.com> <20180329112034.GE31039@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180329112034.GE31039@dhcp22.suse.cz> User-Agent: NeoMutt/20180223 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 29, 2018 at 01:20:34PM +0200, Michal Hocko wrote: > On Wed 28-03-18 19:55:32, Kirill A. Shutemov wrote: > > Modify several page allocation routines to pass down encryption KeyID to > > be used for the allocated page. > > > > There are two basic use cases: > > > > - alloc_page_vma() use VMA's KeyID to allocate the page. > > > > - Page migration and NUMA balancing path use KeyID of original page as > > KeyID for newly allocated page. > > I am sorry but I am out of time to look closer but this just raised my > eyebrows. This looks like a no-go. The basic allocator has no business > in fancy stuff like a encryption key. If you need something like that > then just build a special allocator API on top. This looks like a no-go > to me. The goal is to make memory encryption first class citizen in memory management and not to invent parallel subsysustem (as we did with hugetlb). Making memory encryption integral part of Linux VM would involve handing encrypted page everywhere we expect anonymous page to appear. We can deal with encrypted page allocation with wrappers but it doesn't make sense if we going to use them instead of original API everywhere. -- Kirill A. Shutemov