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;
Message-ID: <1569420226.3642.24.camel@HansenPartnership.com>
Subject: Re: [PATCH] tpm: Detach page allocation from tpm_buf
From:   James Bottomley <James.Bottomley@HansenPartnership.com>
To:     Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
        linux-integrity@vger.kernel.org
Cc:     Mimi Zohar <zohar@linux.ibm.com>,
        Jerry Snitselaar <jsnitsel@redhat.com>,
        Sumit Garg <sumit.garg@linaro.org>,
        Stefan Berger <stefanb@linux.vnet.ibm.com>,
        Peter Huewe <peterhuewe@gmx.de>,
        Jason Gunthorpe <jgg@ziepe.ca>, Arnd Bergmann <arnd@arndb.de>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        open list <linux-kernel@vger.kernel.org>
Date:   Wed, 25 Sep 2019 10:03:46 -0400
In-Reply-To: <20190925134842.19305-1-jarkko.sakkinen@linux.intel.com>
References: <20190925134842.19305-1-jarkko.sakkinen@linux.intel.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, 2019-09-25 at 16:48 +0300, Jarkko Sakkinen wrote:
[...]
> +	data_page = alloc_page(GFP_HIGHUSER);
> +	if (!data_page)
> +		return -ENOMEM;
> +
> +	data_ptr = kmap(data_page);

I don't think this is such a good idea.  On 64 bit it's no different
from GFP_KERNEL and on 32 bit where we do have highmem, kmap space is
at a premium, so doing a highmem allocation + kmap is more wasteful of
resources than simply doing GFP_KERNEL.  In general, you should only do
GFP_HIGHMEM if the page is going to be mostly used by userspace, which
really isn't the case here.

James