Michal Hocko wrote: > On Tue 10-10-17 21:47:02, Tetsuo Handa wrote: > > I think that massive vmalloc() consumers should be (as well as massive > > alloc_page() consumers) careful such that they will be chosen as first OOM > > victim, for vmalloc() does not abort as soon as an OOM occurs. > > No. This would require to spread those checks all over the place. That > is why we have that logic inside the allocator which fails the > allocation at certain point in time. Large/unbound/user controlled sized > allocations from the kernel are always a bug and really hard one to > protect from. It is simply impossible to know the intention. > > > Thus, I used > > set_current_oom_origin()/clear_current_oom_origin() when I demonstrated > > "complete" depletion. > > which was a completely artificial example as already mentioned. > > > > I have tried to explain this is not really needed before but you keep > > > insisting which is highly annoying. The patch as is is not harmful but > > > it is simply _pointless_ IMHO. > > > > Then, how can massive vmalloc() consumers become careful? > > Explicitly use __vmalloc() and pass __GFP_NOMEMALLOC ? > > Then, what about adding some comment like "Never try to allocate large > > memory using plain vmalloc(). Use __vmalloc() with __GFP_NOMEMALLOC." ? > > Come on! Seriously we do expect some competence from the code running in > the kernel space. We do not really need to add a comment that you > shouldn't shoot your head because it might hurt. Please try to focus on > real issues. There are many of them to chase after... > My understanding is that vmalloc() is provided for allocating large memory where kmalloc() is difficult to satisfy. If we say "do not allocate large memory with vmalloc() because large allocations from the kernel are always a bug", it sounds like denial of raison d'etre of vmalloc(). Strange... But anyway, I am not bothered by vmalloc(). What I'm bothered is warn_alloc() lockup. Please go ahead with removal of fatal_signal_pending() for vmalloc(). -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
