On Mon 27-09-21 12:36:15, Vasily Averin wrote: > On 9/24/21 10:55 AM, Michal Hocko wrote: > > On Thu 23-09-21 09:49:57, Vasily Averin wrote: [...] > >> Hypothetically, cancelled vmalloc called inside some filesystem's transaction > >> forces its rollback, that in own turn it can call own vmalloc. > > > > Do you have any specific example? > > No, it was pure hypothetical assumption. > I was thinking about it over the weekend, and decided that: > a) such kind of issue (i.e. vmalloc call in rollback after failed vmalloc) > is very unlikely > b) if it still exists -- it must have own failback with kmalloc(NOFAIL) > or just accept/ignore such failure and should not lead to critical failures. > If this still happen -- ihis is a bug, we should detect and fix it ASAP. I would even argue that nobody should rely on vmalloc suceeding. The purpose of the allocator is to allow larger allocations and we do not guarantee anything even for small reqests. > >> Should we perhaps interrupt the first vmalloc only? > > > > This doesn't make much sense to me TBH. It doesn't address the very > > problem you are describing in the changelog. > > Last question: > how do you think, should we perhaps, instead, detect such vmallocs > (called in rollback after failed vmalloc) and generate a warnings, > to prevent such kind of problems in future? We do provide an allocation failure splat unless the request is explicitly __GFP_NOWARN IIRC. -- Michal Hocko SUSE Labs
