Re: BUG: sleeping function called from invalid context atkernel/locking/mutex.c:616

[Andrew Morton]

On Wed, 04 Dec 2013 16:13:31 +0800 Axel Lin <axel.lin@xxxxxxxxxx> wrote:

> I can constantly hit this issue:
> 
> I trace it to mm/filemap.c: add_to_page_cache_locked
> I print the in_atomic status at BEGIN and END of add_to_page_cache_locked call.
> Then I got in_atomic is true at the end of add_to_page_cache_locked call.
> 
> int add_to_page_cache_locked(struct page *page, struct address_space *mapping,
>                 pgoff_t offset, gfp_t gfp_mask)
> {
>         int error;
> 
>         VM_BUG_ON(!PageLocked(page));
>         VM_BUG_ON(PageSwapBacked(page));
> 
> pr_info(" ##add_to_page_cache_locked BEGIN in_atomic=%d\n", in_atomic());
>         error = mem_cgroup_cache_charge(page, current->mm,
>                                         gfp_mask & GFP_RECLAIM_MASK);
>         if (error)
>                 return error;
> 
>         error = radix_tree_maybe_preload(gfp_mask & ~__GFP_HIGHMEM);
>         if (error) {
>                 mem_cgroup_uncharge_cache_page(page);
>                 return error;
>         }
> 
>         page_cache_get(page);
>         page->mapping = mapping;
>         page->index = offset;
> 
>         spin_lock_irq(&mapping->tree_lock);
>         error = radix_tree_insert(&mapping->page_tree, offset, page);
>         radix_tree_preload_end();
>         if (unlikely(error))
>                 goto err_insert;
>         mapping->nrpages++;
>         __inc_zone_page_state(page, NR_FILE_PAGES);
>         spin_unlock_irq(&mapping->tree_lock);
>         trace_mm_filemap_add_to_page_cache(page);
> pr_info(" ##add_to_page_cache_locked END in_atomic=%d\n", in_atomic());
>         return 0;
> err_insert:
>         page->mapping = NULL;
>         /* Leave page->index set: truncation relies upon it */
>         spin_unlock_irq(&mapping->tree_lock);
>         mem_cgroup_uncharge_cache_page(page);
>         page_cache_release(page);
> pr_info(" ##add_to_page_cache_locked ERR in_atomic=%d\n", in_atomic());
>         return error;
> }
> 
> Then I got below messages:
>  ##add_to_page_cache_locked BEGIN in_atomic=0
>  ##add_to_page_cache_locked END in_atomic=0
>  ##add_to_page_cache_locked BEGIN in_atomic=0
>  ##add_to_page_cache_locked END in_atomic=0
>  ##add_to_page_cache_locked BEGIN in_atomic=0
>  ##add_to_page_cache_locked END in_atomic=1

huh.  I can't spot it.  mem_cgroup_cache_charge() is by far the most
complex callee.

Is tracing enabled?

Is memcg in use?

Please add a lot more printk's so we can narrow it down further?  I'd
use something like 

	printk(%d: %d\n", __LINE__, preempt_count());

(note: preempt_count(), not in_atomic())

Paste that all over the place so we can see which statement is doing
the wrong thing.  

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/