linux-kernel - Re: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:616

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20131204003147.454534da.akpm@linux-foundation.org>
Date:	Wed, 4 Dec 2013 00:31:47 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Axel Lin <axel.lin@...ics.com>
Cc:	linux-kernel@...r.kernel.org, Al Viro <viro@...iv.linux.org.uk>,
	Brian Norris <computersforpeace@...il.com>,
	Artem Bityutskiy <artem.bityutskiy@...ux.intel.com>,
	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
Subject: Re: BUG: sleeping function called from invalid context at
 kernel/locking/mutex.c:616

On Wed, 04 Dec 2013 16:13:31 +0800 Axel Lin <axel.lin@...ics.com> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/