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@xxxxxxxxxxxxxxx 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.
