Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp3487464imm; Mon, 4 Jun 2018 04:33:25 -0700 (PDT) X-Google-Smtp-Source: ADUXVKIXQr3Ribkct8qvkZRmoMYcQcoCpJKK/f1IzVcxJpf1S+otCaCRTme3PrbERqGbUqhOKMxE X-Received: by 2002:a62:6a0a:: with SMTP id f10-v6mr20657827pfc.99.1528112005290; Mon, 04 Jun 2018 04:33:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528112005; cv=none; d=google.com; s=arc-20160816; b=JNHI0hUTkjGVYYZTidOABQl/mfJ511vjPhEEwfOMJhNSagaGF1p9U/3z6DBy6O2mag KDrycRY7oybzF9UgJX3nFInDM6XEzciujac/cdUb7OZGdxxUU1J3bPIDCfJkRKkq8BHD d+tuYWbMvyDIl07V0RKMxZfiYEgqPDAl1ZZVzOCmbgy4fz8lXXlRMwsQAg1CfGlmZ7Q0 QNBxEGxYrZX1agJzFjAhPWIPeX/F8ZshFqrbMYLeod1xM1ygzlrXreEkDAOdHxfkTVrE KEZ17E9yOgWQ0blbZQiFfMk5TpCrQhvSmghiAsWai2X919cA3DzIXn6UKIBNIj534Z0A qYhw== 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:arc-authentication-results; bh=W7tv6apxdRv8/DP17Lul9ARhGaUgQZjWnZUfd+QbLvM=; b=ETa6xdw3EV5lHY2VBu5PkVeIL64RCllUbMSHH6rOs8H5WHmDHhCxg2Ol6oMlZSP7QO kMEvSYrzejJUdDesGqxeTTBJwiuzvD0xhZAPsmvuCjpsCJzzj/gzIgfGDtwDyYHVsS6+ znIJDkwgLZxgm5c9koeDwyWrWtQ9VhznqmRb9nwpx9iC10JxW7T5IXGQZsFEkB7m02T4 f+4T5nBCcw/SbI+TScKHCDTn5hW6Ti8I43zspuiUCNln5QVScW6/BxuZUHuYTx0rQ6T0 AjzrT9Nby3j+Woahw0zoSJ+3cU5zFlWlCFnktA+w+vJGgIfyaeflXH98m3LJUt4RstyM 7cdA== ARC-Authentication-Results: i=1; mx.google.com; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i185-v6si2267737pge.587.2018.06.04.04.33.10; Mon, 04 Jun 2018 04:33:25 -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; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752399AbeFDLcl (ORCPT + 99 others); Mon, 4 Jun 2018 07:32:41 -0400 Received: from mga04.intel.com ([192.55.52.120]:2881 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752246AbeFDLcj (ORCPT ); Mon, 4 Jun 2018 07:32:39 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Jun 2018 04:32:38 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,476,1520924400"; d="scan'208";a="56355443" Received: from black.fi.intel.com ([10.237.72.28]) by orsmga003.jf.intel.com with ESMTP; 04 Jun 2018 04:32:37 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id 5CF9DF5; Mon, 4 Jun 2018 14:32:36 +0300 (EEST) Date: Mon, 4 Jun 2018 14:32:36 +0300 From: "Kirill A. Shutemov" To: Hugh Dickins Cc: Andrew Morton , Josef Bacik , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm/shmem: Zero out unused vma fields in shmem_pseudo_vma_init() Message-ID: <20180604113236.oewgy7jb7frsawg5@black.fi.intel.com> References: <20180531135602.20321-1-kirill.shutemov@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170714-126-deb55f (1.8.3) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 31, 2018 at 10:50:36PM +0000, Hugh Dickins wrote: > On Thu, 31 May 2018, Kirill A. Shutemov wrote: > > > shmem/tmpfs uses pseudo vma to allocate page with correct NUMA policy. > > > > The pseudo vma doesn't have vm_page_prot set. We are going to encode > > encryption KeyID in vm_page_prot. Having garbage there causes problems. > > > > Zero out all unused fields in the pseudo vma. > > > > Signed-off-by: Kirill A. Shutemov > > I won't go so far as to say NAK, but personally I much prefer that we > document what fields actually get used, by initializing only those, > rather than having such a blanket memset. I recognize value of documentation here. But I still think leaving garbage in the fields is not a great idea. > > And you say "We are going to ...": so this should really be part of > some future patchset, shouldn't it? Yeah. It's for MKTME. I just try to push easy patches first. > My opinion might be in the minority: you remind me of a similar > request from Josef some while ago, Cc'ing him. > > (I'm very ashamed, by the way, of shmem's pseudo-vma, I think it's > horrid, and just reflects that shmem was an afterthought when NUMA > mempolicies were designed. Internally, we replaced alloc_pages_vma() > throughout by alloc_pages_mpol(), which has no need for pseudo-vmas, > and the advantage of dropping mmap_sem across the bulk of NUMA page > migration. I shall be updating that work in coming months, and hope > to upstream, but no promise from me on the timing - your need for > vm_page_prot likely much sooner.) I will try to look at how we can get alloc_pages_mpol() implemented. (Although interleave bias is kinda confusing. I'll need to wrap my head around the thing.) -- Kirill A. Shutemov