On Tue, Apr 26, 2022 at 09:17:39AM +0200, Michal Hocko wrote: > I have already touched on that but let me reiterate. Allocation context > called from the oom path will have an unbound access to memory reserves. > Those are a last resort emergency pools of memory that are not available > normally and there are areas which really depend on them to make a > further progress to release the memory pressure. > > Swap over NFS would be one such example. If some other code path messes > with those reserves the swap IO path could fail with all sorts of > fallouts. > > So to be really exact in my statement. You can allocate from the OOM > context but it is _strongly_ discouraged unless there is no other way > around that. > > I would even claim that the memory reclaim in general shouldn't rely on > memory allocations (other than mempools). If an allocation is really > necessary then an extra care has to prevent from complete memory > depletion. 100% agreement with this, I've always made sure IO paths I touched were fully mempool-ified (some of my early work was actually for making sure bio allocation underneath generic_make_request() won't deadlock - previously allocated bios won't make forward progress and be freed due to generic_make_request() turning recursion into iteration, but that's all ancient history). Anyways, the reason I think this allocation is fine is it's GFP_NOWAIT and it's completely fine if it fails - all we lose is some diagnostics, and also it's released right away. But there's also no need for it to be a point of contention, the way I'm going with printbufs it'll be trivial to mempool-ify this if we want. Before I get back to this I'm changing the approach I'm taking with printbufs and first using it to clean up vsnprintf() and all the related code, which is.. a bit of an undertaking. End result is going to be really cool though.
