On Thu 23-09-21 09:49:57, Vasily Averin wrote: [...] > I'm agree that vmalloc callers should expect and handle single vnalloc failures. > I think it is acceptable to enable fatal_signal_pending check to quickly > detect such kind of iussues. > However fatal_signal_pending check can cause serial vmalloc failures > and I doubt it is acceptable. > > Rollback after failed vmalloc can call new vmalloc calls that will be failed too, > even properly handled such serial failures can cause troubles. Could you be more specific? Also how would this be any different from similar failures for an oom victim? Except that the later is less likely so (as already mentioend) any potential bugs would be just lurking there for a longer time. > 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? > Any failures on this path can break the filesystem. > I doubt it is acceptable, especially for non-OOM fatal signals. > On the other hand I cannot say that it is a 100% bug. > > Another scenario: > as you know failed vmalloc calls pr_warn. According message should be sent > to remote terminal or netconsole. I'm not sure about execution context, > however if this is done in task context it may call vmalloc either in terminal > or in network subsystems. Even handled, such failures are not fatal, > but this behaviour is at least unexpected. I do not think we want to shape the vmalloc bahavior based on printk/console behavior. > 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. -- Michal Hocko SUSE Labs
