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 from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
