On Mon, Feb 27, 2017 at 7:25 AM, Michal Hocko <mhocko@xxxxxxxxxx> wrote: > /* > * No space left. Create a new chunk. We don't want multiple > * tasks to create chunks simultaneously. Serialize and create iff > * there's still no empty chunk after grabbing the mutex. > */ > if (is_atomic) > goto fail; > > right before pcpu_populate_chunk so is this actually a problem? Yes, this prevents adding more pcpu chunks and so cause "atomic" allocations to fail more easily. >> By the way, I now noticed the might_sleep() in alloc_vmap_area() which makes >> it unsafe to call vmalloc* in GFP_ATOMIC contexts. It was added recently: > > Do we call alloc_vmap_area from true atomic contexts (aka from under > spinlocks etc)? I thought this was a nogo and GFP_NOWAIT resp. > GFP_ATOMIC was more about optimistic request resp. access to memory > reserves rather than true atomicity requirements. In the call path that I am trying to fix, the caller uses GFP_NOWAIT mask. The caller is holding a spinlock (request_queue->queue_lock) so we can't afford to sleep. -- 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>
