Potential deadlock in stack_depot_save()

google / kmsan

KernelMemorySanitizer, a detector of uses of uninitialized memory in the Linux kernel

Other

406 stars 63 forks source link

Potential deadlock in stack_depot_save() #78

Closed ramosian-glider closed 2 years ago

ramosian-glider commented 4 years ago

When calling stack_depot_save() from within rmqueue() in mm/page_alloc.c (e.g. via __msan_poison_alloca()) it is possible to take a lock twice, which will lead to a deadlock. We already have __no_sanitize_memory for rmqueue(), but it may still poison locals transitively.

Possible solutions:

preallocate a stack depot page somewhere before rmqueue()
call stack_depot_save(..., lock_is_taken() ? GFP_KERNEL : GFP_ATOMIC)

ramosian-glider commented 2 years ago

This is taken care of by the following code:

3818 /*
3819  * Do not instrument rmqueue() with KMSAN. This function may call
3820  * __msan_poison_alloca() through a call to set_pfnblock_flags_mask().
3821  * If __msan_poison_alloca() attempts to allocate pages for the stack depot, it
3822  * may call rmqueue() again, which will result in a deadlock.
3823  */
3824 __no_sanitize_memory
3825 static inline   
3826 struct page *rmqueue(struct zone *preferred_zone,
3827                         struct zone *zone, unsigned int order,
3828                         gfp_t gfp_flags, unsigned int alloc_flags,
3829                         int migratetype)