Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965721Ab2JYUwX (ORCPT ); Thu, 25 Oct 2012 16:52:23 -0400 Received: from zene.cmpxchg.org ([85.214.230.12]:59929 "EHLO zene.cmpxchg.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934995Ab2JYUwV (ORCPT ); Thu, 25 Oct 2012 16:52:21 -0400 Date: Thu, 25 Oct 2012 16:52:13 -0400 From: Johannes Weiner To: Hugh Dickins Cc: Dave Jones , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: shmem_getpage_gfp VM_BUG_ON triggered. [3.7rc2] Message-ID: <20121025205213.GB4771@cmpxchg.org> References: <20121025023738.GA27001@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2816 Lines: 59 On Wed, Oct 24, 2012 at 09:36:27PM -0700, Hugh Dickins wrote: > On Wed, 24 Oct 2012, Dave Jones wrote: > > > Machine under significant load (4gb memory used, swap usage fluctuating) > > triggered this... > > > > WARNING: at mm/shmem.c:1151 shmem_getpage_gfp+0xa5c/0xa70() > > Pid: 29795, comm: trinity-child4 Not tainted 3.7.0-rc2+ #49 > > Call Trace: > > [] warn_slowpath_common+0x7f/0xc0 > > [] warn_slowpath_null+0x1a/0x20 > > [] shmem_getpage_gfp+0xa5c/0xa70 > > [] ? shmem_getpage_gfp+0x29e/0xa70 > > [] shmem_fault+0x4f/0xa0 > > [] __do_fault+0x71/0x5c0 > > [] ? __lock_acquire+0x306/0x1ba0 > > [] ? local_clock+0x89/0xa0 > > [] handle_pte_fault+0x97/0xae0 > > [] ? sub_preempt_count+0x79/0xd0 > > [] ? delay_tsc+0xae/0x120 > > [] ? __const_udelay+0x28/0x30 > > [] handle_mm_fault+0x289/0x350 > > [] __do_page_fault+0x18e/0x530 > > [] ? local_clock+0x89/0xa0 > > [] ? get_parent_ip+0x11/0x50 > > [] ? get_parent_ip+0x11/0x50 > > [] ? sub_preempt_count+0x79/0xd0 > > [] ? rcu_user_exit+0xc9/0xf0 > > [] do_page_fault+0x2b/0x50 > > [] page_fault+0x28/0x30 > > [] ? copy_user_enhanced_fast_string+0x9/0x20 > > [] ? sys_futimesat+0x41/0xe0 > > [] ? syscall_trace_enter+0x25/0x2c0 > > [] ? tracesys+0x7e/0xe6 > > [] tracesys+0xe1/0xe6 > > > > > > > > 1148 error = shmem_add_to_page_cache(page, mapping, index, > > 1149 gfp, swp_to_radix_entry(swap)); > > 1150 /* We already confirmed swap, and make no allocation */ > > 1151 VM_BUG_ON(error); > > 1152 } > > That's very surprising. Easy enough to handle an error there, but > of course I made it a VM_BUG_ON because it violates my assumptions: > I rather need to understand how this can be, and I've no idea. Could it be concurrent truncation clearing out the entry between shmem_confirm_swap() and shmem_add_to_page_cache()? I don't see anything preventing that. The empty slot would not match the expected swap entry this call passes in and the returned error would be -ENOENT. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/