All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To: Mimi Zohar <zohar@linux.ibm.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>,
	linux-integrity@vger.kernel.org,
	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>
Subject: Re: [PATCH] tpm: Detach page allocation from tpm_buf
Date: Thu, 3 Oct 2019 21:26:44 +0300	[thread overview]
Message-ID: <20191003182644.GA20683@linux.intel.com> (raw)
In-Reply-To: <1570107054.4421.174.camel@linux.ibm.com>

On Thu, Oct 03, 2019 at 08:50:54AM -0400, Mimi Zohar wrote:
> On Thu, 2019-10-03 at 14:35 +0300, Jarkko Sakkinen wrote:
> > On Wed, Oct 02, 2019 at 08:41:45AM -0400, Mimi Zohar wrote:
> > > On Fri, 2019-09-27 at 16:06 +0300, Jarkko Sakkinen wrote:
> > > > On Wed, Sep 25, 2019 at 10:03:46AM -0400, James Bottomley wrote:
> > > > > 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.
> > > > 
> > > > Changing that in this commit would be wrong even if you are right.
> > > > After this commit has been applied it is somewhat easier to make
> > > > best choices for allocation in each call site (probably most will
> > > > end up using stack).
> > > 
> > > Agreed, but it could be a separate patch, prior to this one.  Why
> > > duplicate the problem all over only to change it later?
> > 
> > What problem exactly it is duplicating? The existing allocation
> > scheme here works correctly.
> 
> In the current code "alloc_page(GFP_HIGHUSER)" exists in a single
> function.  With this patch, "alloc_page(GFP_HIGHUSER)" is duplicated
> 24 times.  If it is incorrect and we shouldn't be using GFP_HIGHUSER,
> as James said, then why duplicate it 24 times?  Fix it as a separate
> patch first, that could be backported if needed, and then make the
> change.

Sorry I mixed this with Jerry's proposal :-) I can do that of course.

/Jarkko

  reply	other threads:[~2019-10-03 18:26 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-25 13:48 [PATCH] tpm: Detach page allocation from tpm_buf Jarkko Sakkinen
2019-09-25 14:03 ` James Bottomley
2019-09-27 13:06   ` Jarkko Sakkinen
2019-10-02 12:41     ` Mimi Zohar
2019-10-03 11:35       ` Jarkko Sakkinen
2019-10-03 12:50         ` Mimi Zohar
2019-10-03 18:26           ` Jarkko Sakkinen [this message]
2019-09-26 12:46 ` Jarkko Sakkinen
2019-09-26 13:12   ` Jarkko Sakkinen
2019-10-02 12:40     ` Mimi Zohar
2019-10-03 11:32       ` Jarkko Sakkinen
2019-10-03 11:33         ` Jarkko Sakkinen
2019-10-03 15:24           ` Mimi Zohar
2019-10-03 18:33             ` Jarkko Sakkinen
2019-10-03 12:39         ` Mimi Zohar
2019-10-03 18:31           ` Jarkko Sakkinen
  -- strict thread matches above, loose matches on Subject: below --
2019-09-26 17:23 Jarkko Sakkinen
2019-09-27 15:42 ` Jarkko Sakkinen
2019-09-28  7:58 ` Jerry Snitselaar
2019-10-01 20:51   ` Jarkko Sakkinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191003182644.GA20683@linux.intel.com \
    --to=jarkko.sakkinen@linux.intel.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=arnd@arndb.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=jgg@ziepe.ca \
    --cc=jsnitsel@redhat.com \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterhuewe@gmx.de \
    --cc=stefanb@linux.vnet.ibm.com \
    --cc=sumit.garg@linaro.org \
    --cc=zohar@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.