On 5/20/21 1:54 PM, Thomas Gleixner wrote: >> Regarding error return for allocation failures. >> >> I'm not familiar with the use-case where vmalloc would be likely to fail today, >> and I'd be interested if anybody can detail that use-case. > It does not matter whether it's likely or not. Unlikely simply does not > exist at cloud-scale. Len, I may have led you astray in some of our discussions on this topic. Here are the cold hard facts: * vmalloc() can fail (the memory.kmem cgroup limit is probably the most likely place to be exposed to this) * vmalloc() failure in a fault (like #NM) will result in SIGSEGV * vmalloc() failure in a syscall can be handled with -ENOMEM In some of our discussions, I told you that reasonably-sized vmalloc()s don't practically fail and that we shouldn't be concerned with failure for our vmalloc()-in-#NM use-case. In other words, I'm OK with crashing apps at the point that vmalloc() is failing. However, Thomas was pretty clear that he's not OK with that. To paraphrase: if we can avoid expanding the scope of where memory allocation failures result in SIGSEGV, we should do it. While I don't *entirely* agree that it's worth it, I can respect Thomas's opinion here. It leads me in the direction of wanting to drive dynamic xstate vmalloc()s from an explicit syscall ABI. My apologies if I sent the AMX support on an unproductive tangent here.
