From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: linux-integrity@vger.kernel.org
Cc: open list <linux-kernel@vger.kernel.org>,
Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
Jerry Snitselaar <jsnitsel@redhat.com>
Subject: [PATCH v2] tpm: use GFP kernel for tpm_buf allocations
Date: Fri, 11 Oct 2019 09:02:59 -0700 [thread overview]
Message-ID: <1570809779.24157.1.camel@HansenPartnership.com> (raw)
The current code uses GFP_HIGHMEM, which is wrong because GFP_HIGHMEM
(on 32 bit systems) is memory ordinarily inaccessible to the kernel
and should only be used for allocations affecting userspace. In order
to make highmem visible to the kernel on 32 bit it has to be kmapped,
which consumes valuable entries in the kmap region. Since the tpm_buf
is only ever used in the kernel, switch to using a GFP_KERNEL
allocation so as not to waste kmap space on 32 bits.
Fixes: a74f8b36352e (tpm: introduce tpm_buf)
Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com>
Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
---
v2: fix 0day spotted problem with free_page taking an unsigned long
not a void *
---
drivers/char/tpm/tpm.h | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index a7fea3e0ca86..3a7998d7309a 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -284,7 +284,6 @@ enum tpm_buf_flags {
};
struct tpm_buf {
- struct page *data_page;
unsigned int flags;
u8 *data;
};
@@ -300,20 +299,18 @@ static inline void tpm_buf_reset(struct tpm_buf *buf, u16 tag, u32 ordinal)
static inline int tpm_buf_init(struct tpm_buf *buf, u16 tag, u32 ordinal)
{
- buf->data_page = alloc_page(GFP_HIGHUSER);
- if (!buf->data_page)
+ buf->data = (u8 *)__get_free_page(GFP_KERNEL);
+ if (!buf->data)
return -ENOMEM;
buf->flags = 0;
- buf->data = kmap(buf->data_page);
tpm_buf_reset(buf, tag, ordinal);
return 0;
}
static inline void tpm_buf_destroy(struct tpm_buf *buf)
{
- kunmap(buf->data_page);
- __free_page(buf->data_page);
+ free_page((unsigned long)buf->data);
}
static inline u32 tpm_buf_length(struct tpm_buf *buf)
--
2.16.4
next reply other threads:[~2019-10-11 16:03 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-11 16:02 James Bottomley [this message]
2019-10-14 19:32 ` [PATCH v2] tpm: use GFP kernel for tpm_buf allocations Jarkko Sakkinen
2019-10-14 19:35 ` James Bottomley
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=1570809779.24157.1.camel@HansenPartnership.com \
--to=james.bottomley@hansenpartnership.com \
--cc=jarkko.sakkinen@linux.intel.com \
--cc=jsnitsel@redhat.com \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).