From: David Rientjes <rientjes@google.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Peter Gonda <pgonda@google.com>, Andy Nguyen <theflow@google.com>,
stable@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-crypto@vger.kernel.org, John Allen <john.allen@amd.com>,
"Thomas . Lendacky" <thomas.lendacky@amd.com>
Subject: Re: [PATCH] crypto: ccp - Limit memory allocation in SEV_GET_ID2 ioctl
Date: Tue, 27 Dec 2022 17:42:31 -0800 (PST) [thread overview]
Message-ID: <762d33dc-b5fd-d1ef-848c-7de3a6695557@google.com> (raw)
In-Reply-To: <Y5rxd6ZVBqFCBOUT@gondor.apana.org.au>
On Thu, 15 Dec 2022, Herbert Xu wrote:
> On Wed, Dec 14, 2022 at 12:20:46PM -0800, Peter Gonda wrote:
> > Currently userspace can ask for any uint32 size allocation for the
> > SEV_GET_ID2. Limit this allocation size to the max physically
> > contiguously allocation: MAX_ORDER.
>
> This is just to silence the alloc_pages warning, right? If so
> how about adding __GFP_NOWARN instead?
>
The goal was to be more explicit about that, but setting __GFP_NOWARN
would result in the same functional behavior. If we're to go that route,
it would likely be best to add a comment about the limitation.
That said, if AMD would prefer this to be an EINVAL instead of a ENOMEM by
introducing a more formal limitation on the length that can be used, that
would be preferred so that we don't need to rely on the page allocator's
max length to enforce this arbitrarily.
next prev parent reply other threads:[~2022-12-28 1:42 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-14 20:20 [PATCH] crypto: ccp - Limit memory allocation in SEV_GET_ID2 ioctl Peter Gonda
2022-12-15 10:05 ` Herbert Xu
2022-12-28 1:42 ` David Rientjes [this message]
2022-12-28 8:49 ` Herbert Xu
2022-12-30 22:01 ` David Rientjes
2022-12-30 22:18 ` [patch] crypto: ccp - Avoid page allocation failure warning for SEV_GET_ID2 David Rientjes
2023-01-03 14:39 ` Tom Lendacky
2023-01-03 23:18 ` David Rientjes
2023-01-04 14:40 ` Tom Lendacky
2023-01-05 1:49 ` David Rientjes
2023-01-05 15:37 ` Tom Lendacky
2023-01-06 15:18 ` Herbert Xu
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=762d33dc-b5fd-d1ef-848c-7de3a6695557@google.com \
--to=rientjes@google.com \
--cc=herbert@gondor.apana.org.au \
--cc=john.allen@amd.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pgonda@google.com \
--cc=stable@vger.kernel.org \
--cc=theflow@google.com \
--cc=thomas.lendacky@amd.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox