On Sun 03-01-16 20:35:14, Al Viro wrote: [...] > BTW, far scarier one is not GFP_NOFS or GFP_IO - there's a weird > caller passing GFP_ATOMIC to __vmalloc(), for no reason I can guess. > > _That_ really couldn't be handled without passing gfp_t to page allocation > primitives, but I very much doubt that it's needed there at all; it's in > alloc_large_system_hash() and I really cannot imagine a situation when > it would be used in e.g. a nonblocking context. Yeah, this is an __init context. The original commit which has added it doesn't explain GFP_ATOMIC at all. It just converted alloc_bootmem to __vmalloc resp. __get_free_pages based on the size. So we can only guess it wanted to (ab)use memory reserves. -- Michal Hocko SUSE Labs -- 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>