Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 28 Dec 2022 16:49:41 +0800
From:   Herbert Xu <herbert@gondor.apana.org.au>
To:     David Rientjes <rientjes@google.com>
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
Message-ID: <Y6wDJd3hfztLoCp1@gondor.apana.org.au>
References: <20221214202046.719598-1-pgonda@google.com>
 <Y5rxd6ZVBqFCBOUT@gondor.apana.org.au>
 <762d33dc-b5fd-d1ef-848c-7de3a6695557@google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <762d33dc-b5fd-d1ef-848c-7de3a6695557@google.com>
Precedence: bulk

On Tue, Dec 27, 2022 at 05:42:31PM -0800, David Rientjes wrote:
>
> 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.

Ideally the limit should be set according to the object that
you're trying to allocate.  But if that is truly unlimited,
and you don't want to see a warning, then GFP_NOWARN seems to
fit the bill.

Thanks,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt