On Wed, 28 Dec 2022, Herbert Xu wrote:
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.
AMD would be able to speak authoritatively on it, but I think the length of the ID isn't to be assumed by software because it will likely change later.
I don't think there's an active vulnerability with the currnet code so we can likely drop stable@vger.kernel.org for this. The kzalloc() will fail if you try to allocate over 2MB. If you try to allocate >32KB, the page allocator will attempt to reclaim but won't oom kill. If you try to allocate <=32KB, there's the potential for oom kill if nothing is reclaimable, but if memory is that scarce I think we have bigger problems.
So __GFP_NOWARN will work, but I also think it's subtle enough that it warrants being coupled with a comment.