On 3/27/19 4:44 AM, Michal Hocko wrote: >> diff --git a/mm/kmemleak.c b/mm/kmemleak.c >> index a2d894d3de07..7f4545ab1f84 100644 >> --- a/mm/kmemleak.c >> +++ b/mm/kmemleak.c >> @@ -580,7 +580,16 @@ static struct kmemleak_object *create_object(unsigned >> long ptr, size_t size, >> struct rb_node **link, *rb_parent; >> unsigned long untagged_ptr; >> >> - object = kmem_cache_alloc(object_cache, gfp_kmemleak_mask(gfp)); >> + /* >> + * The tracked memory was allocated successful, if the kmemleak object >> + * failed to allocate for some reasons, it ends up with the whole >> + * kmemleak disabled, so try it harder. >> + */ >> + gfp = (in_atomic() || irqs_disabled()) ? >> + gfp_kmemleak_mask(gfp) | GFP_ATOMIC : >> + gfp_kmemleak_mask(gfp) | __GFP_DIRECT_RECLAIM; > > > The comment for in_atomic says: > * Are we running in atomic context? WARNING: this macro cannot > * always detect atomic context; in particular, it cannot know about > * held spinlocks in non-preemptible kernels. Thus it should not be > * used in the general case to determine whether sleeping is possible. > * Do not use in_atomic() in driver code.
That is why it needs both in_atomic() and irqs_disabled(), so irqs_disabled() can detect kernel functions held spinlocks even in non-preemptible kernels. According to [1], "This [2] is useful if you know that the data in question is only ever manipulated from a "process context", ie no interrupts involved." Since kmemleak only deal with kernel context, if a spinlock was held, it always has local interrupt disabled. ftrace is in the same boat where this commit was merged a while back that has the same check. ef99b88b16be tracing: Handle ftrace_dump() atomic context in graph_trace_open() [1] https://www.kernel.org/doc/Documentation/locking/spinlocks.txt [2] spin_lock(&lock); ... spin_unlock(&lock);
