From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx105.postini.com [74.125.245.105]) by kanga.kvack.org (Postfix) with SMTP id 24C396B005D for ; Wed, 24 Oct 2012 22:37:42 -0400 (EDT) Date: Wed, 24 Oct 2012 22:37:38 -0400 From: Dave Jones Subject: shmem_getpage_gfp VM_BUG_ON triggered. [3.7rc2] Message-ID: <20121025023738.GA27001@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-linux-mm@kvack.org List-ID: To: linux-mm@kvack.org Cc: Linux Kernel 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 } total used free shared buffers cached Mem: 3885528 2854064 1031464 0 9624 19208 -/+ buffers/cache: 2825232 1060296 Swap: 6029308 30656 5998652 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx188.postini.com [74.125.245.188]) by kanga.kvack.org (Postfix) with SMTP id 2CAF96B0062 for ; Thu, 25 Oct 2012 00:36:34 -0400 (EDT) Received: by mail-ia0-f169.google.com with SMTP id h37so1265245iak.14 for ; Wed, 24 Oct 2012 21:36:33 -0700 (PDT) Date: Wed, 24 Oct 2012 21:36:27 -0700 (PDT) From: Hugh Dickins Subject: Re: shmem_getpage_gfp VM_BUG_ON triggered. [3.7rc2] In-Reply-To: <20121025023738.GA27001@redhat.com> Message-ID: References: <20121025023738.GA27001@redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org List-ID: To: Dave Jones Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org 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. Clutching at straws, I expect this is entirely irrelevant, but: there isn't a warning on line 1151 of mm/shmem.c in 3.7.0-rc2 nor in current linux.git; rather, there's a VM_BUG_ON on line 1149. So you've inserted a couple of lines for some reason (more useful trinity behaviour, perhaps)? And have some config option I'm unfamiliar with, that mutates a BUG_ON or VM_BUG_ON into a warning? Hugh > > > total used free shared buffers cached > Mem: 3885528 2854064 1031464 0 9624 19208 > -/+ buffers/cache: 2825232 1060296 > Swap: 6029308 30656 5998652 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx166.postini.com [74.125.245.166]) by kanga.kvack.org (Postfix) with SMTP id CD68B6B0070 for ; Thu, 25 Oct 2012 00:50:58 -0400 (EDT) Received: by mail-pa0-f41.google.com with SMTP id fa10so949285pad.14 for ; Wed, 24 Oct 2012 21:50:58 -0700 (PDT) Message-ID: <5088C51D.3060009@gmail.com> Date: Thu, 25 Oct 2012 12:50:37 +0800 From: Ni zhan Chen MIME-Version: 1.0 Subject: Re: shmem_getpage_gfp VM_BUG_ON triggered. [3.7rc2] References: <20121025023738.GA27001@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Hugh Dickins Cc: Dave Jones , linux-mm@kvack.org, linux-kernel@vger.kernel.org On 10/25/2012 12:36 PM, 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. > > Clutching at straws, I expect this is entirely irrelevant, but: > there isn't a warning on line 1151 of mm/shmem.c in 3.7.0-rc2 nor > in current linux.git; rather, there's a VM_BUG_ON on line 1149. > > So you've inserted a couple of lines for some reason (more useful > trinity behaviour, perhaps)? And have some config option I'm > unfamiliar with, that mutates a BUG_ON or VM_BUG_ON into a warning? Hi Hugh, I think it maybe caused by your commit [d189922862e03ce: shmem: fix negative rss in memcg memory.stat], one question: if function shmem_confirm_swap confirm the entry has already brought back from swap by a racing thread, then why call shmem_add_to_page_cache to add page from swapcache to pagecache again? otherwise, will goto unlock and then go to repeat? where I miss? Regards, Chen > > Hugh > >> >> total used free shared buffers cached >> Mem: 3885528 2854064 1031464 0 9624 19208 >> -/+ buffers/cache: 2825232 1060296 >> Swap: 6029308 30656 5998652 > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: email@kvack.org > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx201.postini.com [74.125.245.201]) by kanga.kvack.org (Postfix) with SMTP id 9319A6B0062 for ; Thu, 25 Oct 2012 02:59:50 -0400 (EDT) Received: by mail-pa0-f41.google.com with SMTP id fa10so1024951pad.14 for ; Wed, 24 Oct 2012 23:59:49 -0700 (PDT) Date: Wed, 24 Oct 2012 23:59:40 -0700 (PDT) From: Hugh Dickins Subject: Re: shmem_getpage_gfp VM_BUG_ON triggered. [3.7rc2] In-Reply-To: <5088C51D.3060009@gmail.com> Message-ID: References: <20121025023738.GA27001@redhat.com> <5088C51D.3060009@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org List-ID: To: Ni zhan Chen Cc: Dave Jones , linux-mm@kvack.org, linux-kernel@vger.kernel.org On Thu, 25 Oct 2012, Ni zhan Chen wrote: > On 10/25/2012 12:36 PM, 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 > > > > > > 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. > > > > Clutching at straws, I expect this is entirely irrelevant, but: > > there isn't a warning on line 1151 of mm/shmem.c in 3.7.0-rc2 nor > > in current linux.git; rather, there's a VM_BUG_ON on line 1149. > > > > So you've inserted a couple of lines for some reason (more useful > > trinity behaviour, perhaps)? And have some config option I'm > > unfamiliar with, that mutates a BUG_ON or VM_BUG_ON into a warning? > > Hi Hugh, > > I think it maybe caused by your commit [d189922862e03ce: shmem: fix negative > rss in memcg memory.stat], one question: Well, yes, I added the VM_BUG_ON in that commit. > > if function shmem_confirm_swap confirm the entry has already brought back > from swap by a racing thread, The reverse: true confirms that the swap entry has not been brought back from swap by a racing thread; false indicates that there has been a race. > then why call shmem_add_to_page_cache to add > page from swapcache to pagecache again? Adding it to pagecache again, after such a race, would set error to -EEXIST (originating from radix_tree_insert); but we don't do that, we add it to pagecache when it has not already been added. Or that's the intention: but Dave seems to have found an unexpected exception, despite us holding the page lock across all this. (But if it weren't for the memcg and replace_page issues, I'd much prefer to let shmem_add_to_page_cache discover the race as before.) Hugh > otherwise, will goto unlock and then go to repeat? where I miss? > > Regards, > Chen -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx125.postini.com [74.125.245.125]) by kanga.kvack.org (Postfix) with SMTP id D97F76B0062 for ; Thu, 25 Oct 2012 05:53:21 -0400 (EDT) Received: by mail-ie0-f169.google.com with SMTP id 10so2466308ied.14 for ; Thu, 25 Oct 2012 02:53:21 -0700 (PDT) Message-ID: <50890C06.5060305@gmail.com> Date: Thu, 25 Oct 2012 17:53:10 +0800 From: Ni zhan Chen MIME-Version: 1.0 Subject: Re: shmem_getpage_gfp VM_BUG_ON triggered. [3.7rc2] References: <20121025023738.GA27001@redhat.com> <5088C51D.3060009@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090709030502040204030605" Sender: owner-linux-mm@kvack.org List-ID: To: Hugh Dickins Cc: Dave Jones , linux-mm@kvack.org, linux-kernel@vger.kernel.org This is a multi-part message in MIME format. --------------090709030502040204030605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 10/25/2012 02:59 PM, Hugh Dickins wrote: > On Thu, 25 Oct 2012, Ni zhan Chen wrote: >> On 10/25/2012 12:36 PM, 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 >>>> >>>> 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. >>> >>> Clutching at straws, I expect this is entirely irrelevant, but: >>> there isn't a warning on line 1151 of mm/shmem.c in 3.7.0-rc2 nor >>> in current linux.git; rather, there's a VM_BUG_ON on line 1149. >>> >>> So you've inserted a couple of lines for some reason (more useful >>> trinity behaviour, perhaps)? And have some config option I'm >>> unfamiliar with, that mutates a BUG_ON or VM_BUG_ON into a warning? >> Hi Hugh, >> >> I think it maybe caused by your commit [d189922862e03ce: shmem: fix negative >> rss in memcg memory.stat], one question: > Well, yes, I added the VM_BUG_ON in that commit. > >> if function shmem_confirm_swap confirm the entry has already brought back >> from swap by a racing thread, > The reverse: true confirms that the swap entry has not been brought back > from swap by a racing thread; false indicates that there has been a race. > >> then why call shmem_add_to_page_cache to add >> page from swapcache to pagecache again? > Adding it to pagecache again, after such a race, would set error to > -EEXIST (originating from radix_tree_insert); but we don't do that, > we add it to pagecache when it has not already been added. > > Or that's the intention: but Dave seems to have found an unexpected > exception, despite us holding the page lock across all this. > > (But if it weren't for the memcg and replace_page issues, I'd much > prefer to let shmem_add_to_page_cache discover the race as before.) > > Hugh Hi Hugh Thanks for your response. You mean the -EEXIST originating from radix_tree_insert, in radix_tree_insert: if (slot != NULL) return -EEXIST; But why slot should be NULL? if no race, the pagecache related radix tree entry should be RADIX_TREE_EXCEPTIONAL_ENTRY+swap_entry_t.val, where I miss? Regards, Chen > >> otherwise, will goto unlock and then go to repeat? where I miss? >> >> Regards, >> Chen --------------090709030502040204030605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

On 10/25/2012 02:59 PM, Hugh Dickins wrote:

On Thu, 25 Oct 2012, Ni zhan Chen wrote:

On 10/25/2012 12:36 PM, 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

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.

Clutching at straws, I expect this is entirely irrelevant, but:
there isn't a warning on line 1151 of mm/shmem.c in 3.7.0-rc2 nor
in current linux.git; rather, there's a VM_BUG_ON on line 1149.

So you've inserted a couple of lines for some reason (more useful
trinity behaviour, perhaps)?  And have some config option I'm
unfamiliar with, that mutates a BUG_ON or VM_BUG_ON into a warning?

Hi Hugh,

I think it maybe caused by your commit [d189922862e03ce: shmem: fix negative
rss in memcg memory.stat], one question:

Well, yes, I added the VM_BUG_ON in that commit.

if function shmem_confirm_swap confirm the entry has already brought back
from swap by a racing thread,

The reverse: true confirms that the swap entry has not been brought back
from swap by a racing thread; false indicates that there has been a race.

then why call shmem_add_to_page_cache to add
page from swapcache to pagecache again?

Adding it to pagecache again, after such a race, would set error to
-EEXIST (originating from radix_tree_insert); but we don't do that,
we add it to pagecache when it has not already been added.

Or that's the intention: but Dave seems to have found an unexpected
exception, despite us holding the page lock across all this.

(But if it weren't for the memcg and replace_page issues, I'd much
prefer to let shmem_add_to_page_cache discover the race as before.)

Hugh

Hi Hugh

Thanks for your response. You mean the -EEXIST originating from radix_tree_insert, in radix_tree_insert:
if (slot != NULL)
return -EEXIST;
But why slot should be NULL? if no race, the pagecache related radix tree entry should be RADIX_TREE_EXCEPTIONAL_ENTRY+swap_entry_t.val, where I miss?

Regards,
Chen

otherwise, will goto unlock and then go to repeat? where I miss?

Regards,
Chen

--------------090709030502040204030605-- -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx201.postini.com [74.125.245.201]) by kanga.kvack.org (Postfix) with SMTP id BC80F6B0071 for ; Thu, 25 Oct 2012 06:21:44 -0400 (EDT) Received: by mail-pb0-f41.google.com with SMTP id rq2so2092538pbb.14 for ; Thu, 25 Oct 2012 03:21:44 -0700 (PDT) Message-ID: <508912B0.7080805@gmail.com> Date: Thu, 25 Oct 2012 18:21:36 +0800 From: Ni zhan Chen MIME-Version: 1.0 Subject: Re: shmem_getpage_gfp VM_BUG_ON triggered. [3.7rc2] References: <20121025023738.GA27001@redhat.com> <5088C51D.3060009@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Hugh Dickins Cc: Dave Jones , linux-mm@kvack.org, linux-kernel@vger.kernel.org On 10/25/2012 02:59 PM, Hugh Dickins wrote: > On Thu, 25 Oct 2012, Ni zhan Chen wrote: >> On 10/25/2012 12:36 PM, 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 >>>> >>>> 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. >>> >>> Clutching at straws, I expect this is entirely irrelevant, but: >>> there isn't a warning on line 1151 of mm/shmem.c in 3.7.0-rc2 nor >>> in current linux.git; rather, there's a VM_BUG_ON on line 1149. >>> >>> So you've inserted a couple of lines for some reason (more useful >>> trinity behaviour, perhaps)? And have some config option I'm >>> unfamiliar with, that mutates a BUG_ON or VM_BUG_ON into a warning? >> Hi Hugh, >> >> I think it maybe caused by your commit [d189922862e03ce: shmem: fix negative >> rss in memcg memory.stat], one question: > Well, yes, I added the VM_BUG_ON in that commit. > >> if function shmem_confirm_swap confirm the entry has already brought back >> from swap by a racing thread, > The reverse: true confirms that the swap entry has not been brought back > from swap by a racing thread; false indicates that there has been a race. > >> then why call shmem_add_to_page_cache to add >> page from swapcache to pagecache again? > Adding it to pagecache again, after such a race, would set error to > -EEXIST (originating from radix_tree_insert); but we don't do that, > we add it to pagecache when it has not already been added. > > Or that's the intention: but Dave seems to have found an unexpected > exception, despite us holding the page lock across all this. > > (But if it weren't for the memcg and replace_page issues, I'd much > prefer to let shmem_add_to_page_cache discover the race as before.) > > Hugh Hi Hugh Thanks for your response. You mean the -EEXIST originating from radix_tree_insert, in radix_tree_insert: if (slot != NULL) return -EEXIST; But why slot should be NULL? if no race, the pagecache related radix tree entry should be RADIX_TREE_EXCEPTIONAL_ENTRY+swap_entry_t.val, where I miss? Regards, Chen > >> otherwise, will goto unlock and then go to repeat? where I miss? >> >> Regards, >> Chen -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx142.postini.com [74.125.245.142]) by kanga.kvack.org (Postfix) with SMTP id 850996B0062 for ; Thu, 25 Oct 2012 07:14:15 -0400 (EDT) Date: Thu, 25 Oct 2012 07:14:11 -0400 From: Dave Jones Subject: Re: shmem_getpage_gfp VM_BUG_ON triggered. [3.7rc2] Message-ID: <20121025111411.GB24886@redhat.com> References: <20121025023738.GA27001@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: Hugh Dickins Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org On Wed, Oct 24, 2012 at 09:36:27PM -0700, Hugh Dickins wrote: > > 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. > > Clutching at straws, I expect this is entirely irrelevant, but: > there isn't a warning on line 1151 of mm/shmem.c in 3.7.0-rc2 nor > in current linux.git; rather, there's a VM_BUG_ON on line 1149. > > So you've inserted a couple of lines for some reason (more useful > trinity behaviour, perhaps)? detritus from the recent mpol_to_str bug that I was chasing. Shouldn't be relevant... diff -durpN '--exclude-from=/home/davej/.exclude' src/git-trees/kernel/linux/mm> --- src/git-trees/kernel/linux/mm/shmem.c 2012-10-12 10:01:46.613408580 -> +++ linux-dj/mm/shmem.c 2012-10-15 12:31:32.979653309 -0400 @@ -885,13 +885,15 @@ redirty: static void shmem_show_mpol(struct seq_file *seq, struct mempolicy *mpol) { char buffer[64]; + int ret; if (!mpol || mpol->mode == MPOL_DEFAULT) return; /* show nothing */ - mpol_to_str(buffer, sizeof(buffer), mpol, 1); - - seq_printf(seq, ",mpol=%s", buffer); + memset(buffer, 0, sizeof(buffer)); + ret = mpol_to_str(buffer, sizeof(buffer), mpol, 1); + if (ret > 0) + seq_printf(seq, ",mpol=%s", buffer); } > And have some config option I'm > unfamiliar with, that mutates a BUG_ON or VM_BUG_ON into a warning? Yes, I do have this.. -#define VM_BUG_ON(cond) BUG_ON(cond) +#define VM_BUG_ON(cond) WARN_ON(cond) because I got tired of things not going over my usb serial port when I hit them a while ago. BUG_ON is pretty unfriendly to bug finding. Dave -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx124.postini.com [74.125.245.124]) by kanga.kvack.org (Postfix) with SMTP id 9249E6B0072 for ; Thu, 25 Oct 2012 16:52:19 -0400 (EDT) Date: Thu, 25 Oct 2012 16:52:13 -0400 From: Johannes Weiner 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: owner-linux-mm@kvack.org List-ID: To: Hugh Dickins Cc: Dave Jones , linux-mm@kvack.org, linux-kernel@vger.kernel.org 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, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx104.postini.com [74.125.245.104]) by kanga.kvack.org (Postfix) with SMTP id 0F70D6B0072 for ; Thu, 25 Oct 2012 17:27:47 -0400 (EDT) Received: by mail-ie0-f169.google.com with SMTP id 10so3668133ied.14 for ; Thu, 25 Oct 2012 14:27:46 -0700 (PDT) Date: Thu, 25 Oct 2012 14:27:41 -0700 (PDT) From: Hugh Dickins Subject: Re: shmem_getpage_gfp VM_BUG_ON triggered. [3.7rc2] In-Reply-To: <508912B0.7080805@gmail.com> Message-ID: References: <20121025023738.GA27001@redhat.com> <5088C51D.3060009@gmail.com> <508912B0.7080805@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org List-ID: To: Ni zhan Chen Cc: Dave Jones , linux-mm@kvack.org, linux-kernel@vger.kernel.org On Thu, 25 Oct 2012, Ni zhan Chen wrote: > On 10/25/2012 02:59 PM, Hugh Dickins wrote: > > On Thu, 25 Oct 2012, Ni zhan Chen wrote: > > > > > > I think it maybe caused by your commit [d189922862e03ce: shmem: fix > > > negative > > > rss in memcg memory.stat], one question: > > Well, yes, I added the VM_BUG_ON in that commit. > > > > > if function shmem_confirm_swap confirm the entry has already brought back > > > from swap by a racing thread, > > The reverse: true confirms that the swap entry has not been brought back > > from swap by a racing thread; false indicates that there has been a race. > > > > > then why call shmem_add_to_page_cache to add > > > page from swapcache to pagecache again? > > Adding it to pagecache again, after such a race, would set error to > > -EEXIST (originating from radix_tree_insert); but we don't do that, > > we add it to pagecache when it has not already been added. > > > > Or that's the intention: but Dave seems to have found an unexpected > > exception, despite us holding the page lock across all this. > > > > (But if it weren't for the memcg and replace_page issues, I'd much > > prefer to let shmem_add_to_page_cache discover the race as before.) > > > > Hugh > > Hi Hugh > > Thanks for your response. You mean the -EEXIST originating from > radix_tree_insert, in radix_tree_insert: > if (slot != NULL) > return -EEXIST; > But why slot should be NULL? if no race, the pagecache related radix tree > entry should be RADIX_TREE_EXCEPTIONAL_ENTRY+swap_entry_t.val, where I miss? I was describing what would happen in a case that should not exist, that you had thought the common case. In actuality, the entry should not be NULL, it should be as you say there. Hugh -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx116.postini.com [74.125.245.116]) by kanga.kvack.org (Postfix) with SMTP id 8C0B76B0072 for ; Thu, 25 Oct 2012 17:28:59 -0400 (EDT) Received: by mail-ie0-f169.google.com with SMTP id 10so3669620ied.14 for ; Thu, 25 Oct 2012 14:28:59 -0700 (PDT) Date: Thu, 25 Oct 2012 14:28:59 -0700 (PDT) From: Hugh Dickins Subject: Re: shmem_getpage_gfp VM_BUG_ON triggered. [3.7rc2] In-Reply-To: <20121025111411.GB24886@redhat.com> Message-ID: References: <20121025023738.GA27001@redhat.com> <20121025111411.GB24886@redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org List-ID: To: Dave Jones , Hugh Dickins , linux-mm@kvack.org, linux-kernel@vger.kernel.org On Thu, 25 Oct 2012, Dave Jones wrote: > On Wed, Oct 24, 2012 at 09:36:27PM -0700, Hugh Dickins wrote: > > > Clutching at straws, I expect this is entirely irrelevant, but: > > there isn't a warning on line 1151 of mm/shmem.c in 3.7.0-rc2 nor > > in current linux.git; rather, there's a VM_BUG_ON on line 1149. > > > > So you've inserted a couple of lines for some reason (more useful > > trinity behaviour, perhaps)? > > detritus from the recent mpol_to_str bug that I was chasing. > Shouldn't be relevant... > > > And have some config option I'm > > unfamiliar with, that mutates a BUG_ON or VM_BUG_ON into a warning? > > Yes, I do have this.. > > -#define VM_BUG_ON(cond) BUG_ON(cond) > +#define VM_BUG_ON(cond) WARN_ON(cond) > > because I got tired of things not going over my usb serial port when I hit them > a while ago. BUG_ON is pretty unfriendly to bug finding. Makes sense, thanks for the reassurance. Hugh -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx197.postini.com [74.125.245.197]) by kanga.kvack.org (Postfix) with SMTP id 48CCE6B0072 for ; Thu, 25 Oct 2012 17:48:39 -0400 (EDT) Received: by mail-ie0-f169.google.com with SMTP id 10so3695746ied.14 for ; Thu, 25 Oct 2012 14:48:38 -0700 (PDT) Date: Thu, 25 Oct 2012 14:48:39 -0700 (PDT) From: Hugh Dickins Subject: Re: shmem_getpage_gfp VM_BUG_ON triggered. [3.7rc2] In-Reply-To: <20121025205213.GB4771@cmpxchg.org> Message-ID: References: <20121025023738.GA27001@redhat.com> <20121025205213.GB4771@cmpxchg.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org List-ID: To: Johannes Weiner Cc: Dave Jones , linux-mm@kvack.org, linux-kernel@vger.kernel.org On Thu, 25 Oct 2012, Johannes Weiner wrote: > 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 > > > > > > 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. Excellent notion, many thanks Hannes, I believe you've got it. I've hit that truncation problem in swapoff (and commented on it in shmem_unuse_inode), but never hit it or considered it here. I think of the page lock as holding it stable, but truncation's free_swap_and_cache only does a trylock on the swapcache page, so we're not secured against that possibility. So I'd like to change it to VM_BUG_ON(error && error != -ENOENT), but there's a little tidying up to do in the -ENOENT case, which needs more thought. A delete_from_swap_cache(page) - though we can be lazy and leave that to reclaim for such a rare occurrence - and probably a mem_cgroup uncharge; but the memcg hooks are always the hardest to get right, I'll have think about that one carefully. Hugh -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx196.postini.com [74.125.245.196]) by kanga.kvack.org (Postfix) with SMTP id 9DC246B0071 for ; Thu, 25 Oct 2012 21:48:29 -0400 (EDT) Received: by mail-da0-f41.google.com with SMTP id i14so1160662dad.14 for ; Thu, 25 Oct 2012 18:48:28 -0700 (PDT) Message-ID: <5089EBE1.1050009@gmail.com> Date: Fri, 26 Oct 2012 09:48:17 +0800 From: Ni zhan Chen MIME-Version: 1.0 Subject: Re: shmem_getpage_gfp VM_BUG_ON triggered. [3.7rc2] References: <20121025023738.GA27001@redhat.com> <5088C51D.3060009@gmail.com> <508912B0.7080805@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Hugh Dickins Cc: Dave Jones , linux-mm@kvack.org, linux-kernel@vger.kernel.org On 10/26/2012 05:27 AM, Hugh Dickins wrote: > On Thu, 25 Oct 2012, Ni zhan Chen wrote: >> On 10/25/2012 02:59 PM, Hugh Dickins wrote: >>> On Thu, 25 Oct 2012, Ni zhan Chen wrote: >>>> I think it maybe caused by your commit [d189922862e03ce: shmem: fix >>>> negative >>>> rss in memcg memory.stat], one question: >>> Well, yes, I added the VM_BUG_ON in that commit. >>> >>>> if function shmem_confirm_swap confirm the entry has already brought back >>>> from swap by a racing thread, >>> The reverse: true confirms that the swap entry has not been brought back >>> from swap by a racing thread; false indicates that there has been a race. >>> >>>> then why call shmem_add_to_page_cache to add >>>> page from swapcache to pagecache again? >>> Adding it to pagecache again, after such a race, would set error to >>> -EEXIST (originating from radix_tree_insert); but we don't do that, >>> we add it to pagecache when it has not already been added. >>> >>> Or that's the intention: but Dave seems to have found an unexpected >>> exception, despite us holding the page lock across all this. >>> >>> (But if it weren't for the memcg and replace_page issues, I'd much >>> prefer to let shmem_add_to_page_cache discover the race as before.) >>> >>> Hugh >> Hi Hugh >> >> Thanks for your response. You mean the -EEXIST originating from >> radix_tree_insert, in radix_tree_insert: >> if (slot != NULL) >> return -EEXIST; >> But why slot should be NULL? if no race, the pagecache related radix tree >> entry should be RADIX_TREE_EXCEPTIONAL_ENTRY+swap_entry_t.val, where I miss? > I was describing what would happen in a case that should not exist, > that you had thought the common case. In actuality, the entry should > not be NULL, it should be as you say there. Thanks for your patience. So in the common case, the entry should be the value I mentioned, then why has this check? if (slot != NULL) return -EEXIST; the common case will return -EEXIST. > > Hugh > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx140.postini.com [74.125.245.140]) by kanga.kvack.org (Postfix) with SMTP id 902A56B0072 for ; Thu, 25 Oct 2012 22:15:17 -0400 (EDT) Received: by mail-ia0-f169.google.com with SMTP id h37so2318852iak.14 for ; Thu, 25 Oct 2012 19:15:16 -0700 (PDT) Message-ID: <5089F22D.70007@gmail.com> Date: Fri, 26 Oct 2012 10:15:09 +0800 From: Ni zhan Chen MIME-Version: 1.0 Subject: Re: shmem_getpage_gfp VM_BUG_ON triggered. [3.7rc2] References: <20121025023738.GA27001@redhat.com> <20121025205213.GB4771@cmpxchg.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Hugh Dickins Cc: Johannes Weiner , Dave Jones , linux-mm@kvack.org, linux-kernel@vger.kernel.org On 10/26/2012 05:48 AM, Hugh Dickins wrote: > On Thu, 25 Oct 2012, Johannes Weiner wrote: >> 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 >>>> >>>> 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. > Excellent notion, many thanks Hannes, I believe you've got it. > > I've hit that truncation problem in swapoff (and commented on it > in shmem_unuse_inode), but never hit it or considered it here. > I think of the page lock as holding it stable, but truncation's > free_swap_and_cache only does a trylock on the swapcache page, > so we're not secured against that possibility. Hi Hugh, Even though free_swap_and_cache only does a trylock on the swapcache page, but it doens't call delete_from_swap_cache and the associated entry should still be there, I am interested in what you have already introduce to protect it? > > So I'd like to change it to VM_BUG_ON(error && error != -ENOENT), > but there's a little tidying up to do in the -ENOENT case, which Do you mean radix_tree_insert will return -ENOENT if the associated entry is not present? Why I can't find this return value in the function radix_tree_insert? > needs more thought. A delete_from_swap_cache(page) - though we > can be lazy and leave that to reclaim for such a rare occurrence - > and probably a mem_cgroup uncharge; but the memcg hooks are always > the hardest to get right, I'll have think about that one carefully. > > Hugh > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: email@kvack.org > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx178.postini.com [74.125.245.178]) by kanga.kvack.org (Postfix) with SMTP id 14C946B004D for ; Thu, 1 Nov 2012 15:10:57 -0400 (EDT) Date: Thu, 1 Nov 2012 15:10:52 -0400 From: Dave Jones Subject: Re: shmem_getpage_gfp VM_BUG_ON triggered. [3.7rc2] Message-ID: <20121101191052.GA5884@redhat.com> References: <20121025023738.GA27001@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: Hugh Dickins Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org 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. I just noticed we had a user report hitting this same warning, but with a different trace.. : [] warn_slowpath_common+0x7f/0xc0 : [] warn_slowpath_null+0x1a/0x20 : [] shmem_getpage_gfp+0x7f3/0x830 : [] ? vma_adjust+0x3ed/0x620 : [] shmem_file_aio_read+0x1f2/0x380 : [] do_sync_read+0xa7/0xe0 : [] vfs_read+0xa9/0x180 : [] sys_read+0x4a/0x90 : [] system_call_fastpath+0x16/0x1b Dave -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx128.postini.com [74.125.245.128]) by kanga.kvack.org (Postfix) with SMTP id 8868F6B0075 for ; Thu, 1 Nov 2012 19:03:44 -0400 (EDT) Received: by mail-ie0-f169.google.com with SMTP id 10so5317236ied.14 for ; Thu, 01 Nov 2012 16:03:43 -0700 (PDT) Date: Thu, 1 Nov 2012 16:03:40 -0700 (PDT) From: Hugh Dickins Subject: Re: shmem_getpage_gfp VM_BUG_ON triggered. [3.7rc2] In-Reply-To: <20121101191052.GA5884@redhat.com> Message-ID: References: <20121025023738.GA27001@redhat.com> <20121101191052.GA5884@redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org List-ID: To: Dave Jones Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org On Thu, 1 Nov 2012, Dave Jones wrote: > 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() > > > > > > 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. > > I just noticed we had a user report hitting this same warning, but > with a different trace.. > > : [] warn_slowpath_common+0x7f/0xc0 > : [] warn_slowpath_null+0x1a/0x20 > : [] shmem_getpage_gfp+0x7f3/0x830 > : [] ? vma_adjust+0x3ed/0x620 > : [] shmem_file_aio_read+0x1f2/0x380 > : [] do_sync_read+0xa7/0xe0 > : [] vfs_read+0xa9/0x180 > : [] sys_read+0x4a/0x90 > : [] system_call_fastpath+0x16/0x1b Equally explicable by Hannes's hypothesis; but useful supporting evidence, thank you. Except... earlier in the thread you explained how you hacked #define VM_BUG_ON(cond) WARN_ON(cond) to get this to come out as a warning instead of a bug, and now it looks as if "a user" has here done the same. Which is very much a user's right, of course; but does make me wonder whether that user might actually be davej ;) Never mind, whatever, it's more justification for the fix - which I've honestly not forgotten, but somehow not got around to sending (with a couple of others even longer outstanding). On its way shortly, for some unpredictable value of shortly. Hugh -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx132.postini.com [74.125.245.132]) by kanga.kvack.org (Postfix) with SMTP id 793926B0068 for ; Thu, 1 Nov 2012 19:20:34 -0400 (EDT) Date: Thu, 1 Nov 2012 19:20:30 -0400 From: Dave Jones Subject: Re: shmem_getpage_gfp VM_BUG_ON triggered. [3.7rc2] Message-ID: <20121101232030.GA25519@redhat.com> References: <20121025023738.GA27001@redhat.com> <20121101191052.GA5884@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: Hugh Dickins Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org On Thu, Nov 01, 2012 at 04:03:40PM -0700, Hugh Dickins wrote: > > I just noticed we had a user report hitting this same warning, but > > with a different trace.. > > > > : [] warn_slowpath_common+0x7f/0xc0 > > : [] warn_slowpath_null+0x1a/0x20 > > : [] shmem_getpage_gfp+0x7f3/0x830 > > : [] ? vma_adjust+0x3ed/0x620 > > : [] shmem_file_aio_read+0x1f2/0x380 > > : [] do_sync_read+0xa7/0xe0 > > : [] vfs_read+0xa9/0x180 > > : [] sys_read+0x4a/0x90 > > : [] system_call_fastpath+0x16/0x1b > > Equally explicable by Hannes's hypothesis; > but useful supporting evidence, thank you. > > Except... earlier in the thread you explained how you hacked > #define VM_BUG_ON(cond) WARN_ON(cond) > to get this to come out as a warning instead of a bug, > and now it looks as if "a user" has here done the same. > > Which is very much a user's right, of course; but does > make me wonder whether that user might actually be davej ;) indirectly. I made the same change in the Fedora kernel a while ago to test a hypothesis that we weren't getting any VM_BUG_ON reports. Dave -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx125.postini.com [74.125.245.125]) by kanga.kvack.org (Postfix) with SMTP id 72C0F6B004D for ; Thu, 1 Nov 2012 19:48:46 -0400 (EDT) Received: by mail-ie0-f169.google.com with SMTP id 10so5364784ied.14 for ; Thu, 01 Nov 2012 16:48:45 -0700 (PDT) Date: Thu, 1 Nov 2012 16:48:41 -0700 (PDT) From: Hugh Dickins Subject: Re: shmem_getpage_gfp VM_BUG_ON triggered. [3.7rc2] In-Reply-To: <20121101232030.GA25519@redhat.com> Message-ID: References: <20121025023738.GA27001@redhat.com> <20121101191052.GA5884@redhat.com> <20121101232030.GA25519@redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org List-ID: To: Dave Jones , linux-mm@kvack.org, linux-kernel@vger.kernel.org On Thu, 1 Nov 2012, Dave Jones wrote: > On Thu, Nov 01, 2012 at 04:03:40PM -0700, Hugh Dickins wrote: > > > > Except... earlier in the thread you explained how you hacked > > #define VM_BUG_ON(cond) WARN_ON(cond) > > to get this to come out as a warning instead of a bug, > > and now it looks as if "a user" has here done the same. > > > > Which is very much a user's right, of course; but does > > make me wonder whether that user might actually be davej ;) > > indirectly. I made the same change in the Fedora kernel a while ago > to test a hypothesis that we weren't getting any VM_BUG_ON reports. Fedora turns on CONFIG_DEBUG_VM? All mm developers should thank you for the wider testing exposure; but I'm not so sure that Fedora users should thank you for turning it on - really it's for mm developers to wrap around !assertions or more expensive checks (e.g. checking calls) in their development. Or did I read a few months ago that some change had been made to such definitions, and VM_BUG_ON(contents) are evaluated even when the config option is off? I do hope I'm mistaken on that. Hugh -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx168.postini.com [74.125.245.168]) by kanga.kvack.org (Postfix) with SMTP id 5830B6B004D for ; Thu, 1 Nov 2012 21:43:42 -0400 (EDT) Date: Thu, 1 Nov 2012 21:43:36 -0400 From: Dave Jones Subject: Re: shmem_getpage_gfp VM_BUG_ON triggered. [3.7rc2] Message-ID: <20121102014336.GA1727@redhat.com> References: <20121025023738.GA27001@redhat.com> <20121101191052.GA5884@redhat.com> <20121101232030.GA25519@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: Hugh Dickins Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org On Thu, Nov 01, 2012 at 04:48:41PM -0700, Hugh Dickins wrote: > On Thu, 1 Nov 2012, Dave Jones wrote: > > On Thu, Nov 01, 2012 at 04:03:40PM -0700, Hugh Dickins wrote: > > > > > > Except... earlier in the thread you explained how you hacked > > > #define VM_BUG_ON(cond) WARN_ON(cond) > > > to get this to come out as a warning instead of a bug, > > > and now it looks as if "a user" has here done the same. > > > > > > Which is very much a user's right, of course; but does > > > make me wonder whether that user might actually be davej ;) > > > > indirectly. I made the same change in the Fedora kernel a while ago > > to test a hypothesis that we weren't getting any VM_BUG_ON reports. > > Fedora turns on CONFIG_DEBUG_VM? Yes. > All mm developers should thank you for the wider testing exposure; > but I'm not so sure that Fedora users should thank you for turning > it on - really it's for mm developers to wrap around !assertions or > more expensive checks (e.g. checking calls) in their development. The last time I did some benchmarking the impact wasn't as ridiculous as say lockdep, or spinlock debug. Maybe the benchmarks I was using weren't pushing the VM very hard, but it seemed to me that the value in getting info in potential problems early was higher than a small performance increase. > Or did I read a few months ago that some change had been made to > such definitions, and VM_BUG_ON(contents) are evaluated even when > the config option is off? I do hope I'm mistaken on that. Pretty sure that isn't the case. I remember Andrew chastising people a few times for putting checks in VM_BUG_ON's that needed to stay around even when the config option was off. Perhaps you were thinking of one of those incidents ? Dave -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx148.postini.com [74.125.245.148]) by kanga.kvack.org (Postfix) with SMTP id 35CF46B0044 for ; Fri, 2 Nov 2012 19:26:00 -0400 (EDT) Received: by mail-ie0-f169.google.com with SMTP id 10so7148628ied.14 for ; Fri, 02 Nov 2012 16:25:59 -0700 (PDT) Date: Fri, 2 Nov 2012 16:26:03 -0700 (PDT) From: Hugh Dickins Subject: Re: shmem_getpage_gfp VM_BUG_ON triggered. [3.7rc2] In-Reply-To: <20121102014336.GA1727@redhat.com> Message-ID: References: <20121025023738.GA27001@redhat.com> <20121101191052.GA5884@redhat.com> <20121101232030.GA25519@redhat.com> <20121102014336.GA1727@redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org List-ID: To: Dave Jones Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org On Thu, 1 Nov 2012, Dave Jones wrote: > On Thu, Nov 01, 2012 at 04:48:41PM -0700, Hugh Dickins wrote: > > > > Fedora turns on CONFIG_DEBUG_VM? > > Yes. > > > All mm developers should thank you for the wider testing exposure; > > but I'm not so sure that Fedora users should thank you for turning > > it on - really it's for mm developers to wrap around !assertions or > > more expensive checks (e.g. checking calls) in their development. > > The last time I did some benchmarking the impact wasn't as ridiculous > as say lockdep, or spinlock debug. I think you're safe to assume that (outside of an individual developer's private tree) it will never be nearly as heavy as lockdep or debug pagealloc. I hadn't thought of spinlock debug as a heavy one, but yes, I guess it would be heavier than almost all VM_BUG_ON()s. > Maybe the benchmarks I was using > weren't pushing the VM very hard, but it seemed to me that the value > in getting info in potential problems early was higher than a small > performance increase. We thank you. I may have been over-estimating how much we put inside those VM_BUG_ON()s, sorry. Just so long as you're aware that there's a danger that one day we might slip something heavier in there. Those few explicit #ifdef CONFIG_DEBUG_VMs sometimes found in mm/ are probably the worst: you might want to check on the current crop. > > > Or did I read a few months ago that some change had been made to > > such definitions, and VM_BUG_ON(contents) are evaluated even when > > the config option is off? I do hope I'm mistaken on that. > > Pretty sure that isn't the case. I remember Andrew chastising people > a few times for putting checks in VM_BUG_ON's that needed to stay around > even when the config option was off. Perhaps you were thinking of one > of those incidents ? Avoiding side-effects in BUG_ON and VM_BUG_ON. Yes, that comes up from time to time, and I'm a believer on that. I think the discussion I'm mis/remembering sprung out of one of those: someone was surprised by the disassembly they found when it was configured off. The correct answer is to try it for myself and see. Not today. Hugh -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx172.postini.com [74.125.245.172]) by kanga.kvack.org (Postfix) with SMTP id 25F7E6B004D for ; Mon, 5 Nov 2012 20:32:47 -0500 (EST) Received: by mail-ie0-f169.google.com with SMTP id 10so11318678ied.14 for ; Mon, 05 Nov 2012 17:32:46 -0800 (PST) Date: Mon, 5 Nov 2012 17:32:41 -0800 (PST) From: Hugh Dickins Subject: [PATCH] tmpfs: fix shmem_getpage_gfp VM_BUG_ON In-Reply-To: Message-ID: References: <20121025023738.GA27001@redhat.com> <20121101191052.GA5884@redhat.com> <20121101232030.GA25519@redhat.com> <20121102014336.GA1727@redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org List-ID: To: Andrew Morton Cc: Dave Jones , Johannes Weiner , linux-mm@kvack.org, linux-kernel@vger.kernel.org Fuzzing with trinity hit the "impossible" VM_BUG_ON(error) (which Fedora has converted to WARNING) in shmem_getpage_gfp(): 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_fault+0x4f/0xa0 [] __do_fault+0x71/0x5c0 [] handle_pte_fault+0x97/0xae0 [] handle_mm_fault+0x289/0x350 [] __do_page_fault+0x18e/0x530 [] do_page_fault+0x2b/0x50 [] page_fault+0x28/0x30 [] tracesys+0xe1/0xe6 Thanks to Johannes for pointing to truncation: free_swap_and_cache() only does a trylock on the page, so the page lock we've held since before confirming swap is not enough to protect against truncation. What cleanup is needed in this case? Just delete_from_swap_cache(), which takes care of the memcg uncharge. Reported-by: Dave Jones Hypothesis-by: Johannes Weiner Signed-off-by: Hugh Dickins Cc: stable@vger.kernel.org --- mm/shmem.c | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) --- 3.7-rc4/mm/shmem.c 2012-10-14 16:16:58.361309122 -0700 +++ linux/mm/shmem.c 2012-11-01 14:31:04.288185742 -0700 @@ -1145,8 +1145,22 @@ repeat: if (!error) { error = shmem_add_to_page_cache(page, mapping, index, gfp, swp_to_radix_entry(swap)); - /* We already confirmed swap, and make no allocation */ - VM_BUG_ON(error); + /* + * We already confirmed swap under page lock, and make + * no memory allocation here, so usually no possibility + * of error; but free_swap_and_cache() only trylocks a + * page, so it is just possible that the entry has been + * truncated or holepunched since swap was confirmed. + * shmem_undo_range() will have done some of the + * unaccounting, now delete_from_swap_cache() will do + * the rest (including mem_cgroup_uncharge_swapcache). + * Reset swap.val? No, leave it so "failed" goes back to + * "repeat": reading a hole and writing should succeed. + */ + if (error) { + VM_BUG_ON(error != -ENOENT); + delete_from_swap_cache(page); + } } if (error) goto failed; -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx172.postini.com [74.125.245.172]) by kanga.kvack.org (Postfix) with SMTP id A4D776B004D for ; Tue, 6 Nov 2012 08:54:10 -0500 (EST) Date: Tue, 6 Nov 2012 08:54:02 -0500 From: Dave Jones Subject: Re: [PATCH] tmpfs: fix shmem_getpage_gfp VM_BUG_ON Message-ID: <20121106135402.GA3543@redhat.com> References: <20121025023738.GA27001@redhat.com> <20121101191052.GA5884@redhat.com> <20121101232030.GA25519@redhat.com> <20121102014336.GA1727@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: Hugh Dickins Cc: Andrew Morton , Johannes Weiner , linux-mm@kvack.org, linux-kernel@vger.kernel.org On Mon, Nov 05, 2012 at 05:32:41PM -0800, Hugh Dickins wrote: > - /* We already confirmed swap, and make no allocation */ > - VM_BUG_ON(error); > + /* > + * We already confirmed swap under page lock, and make > + * no memory allocation here, so usually no possibility > + * of error; but free_swap_and_cache() only trylocks a > + * page, so it is just possible that the entry has been > + * truncated or holepunched since swap was confirmed. > + * shmem_undo_range() will have done some of the > + * unaccounting, now delete_from_swap_cache() will do > + * the rest (including mem_cgroup_uncharge_swapcache). > + * Reset swap.val? No, leave it so "failed" goes back to > + * "repeat": reading a hole and writing should succeed. > + */ > + if (error) { > + VM_BUG_ON(error != -ENOENT); > + delete_from_swap_cache(page); > + } > } I ran with this overnight, and still hit the (new!) VM_BUG_ON Perhaps we should print out what 'error' was too ? I'll rebuild with that.. ------------[ cut here ]------------ WARNING: at mm/shmem.c:1151 shmem_getpage_gfp+0xa5c/0xa70() Hardware name: 2012 Client Platform Modules linked in: fuse ipt_ULOG scsi_transport_iscsi binfmt_misc dn_rtmsg nfnetlink nfc caif_socket caif af_802154 phonet af_rxrpc can llc2 pppoe pppox ppp_generic slhc irda crc_ccitt rds af_key decnet rose x25 atm netrom appletalk ipx p8023 p8022 psnap llc ax25 lockd sunrpc bluetooth rfkill ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables gspca_ov519 gspca_main videodev kvm_intel usb_debug kvm crc32c_intel ghash_clmulni_intel microcode pcspkr i2c_i801 e1000e uinput i915 video i2c_algo_bit drm_kms_helper drm i2c_core Pid: 21798, comm: trinity-child4 Not tainted 3.7.0-rc4+ #54 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 [] ? getname_flags.part.32+0x30/0x150 [] ? getname_flags.part.32+0x30/0x150 [] ? set_track+0x8c/0x1a0 [] ? __slab_alloc+0x531/0x59e [] ? trace_hardirqs_on_caller+0x15d/0x1e0 [] ? rcu_user_exit+0xc9/0xf0 [] do_page_fault+0x2b/0x50 [] page_fault+0x28/0x30 [] ? strncpy_from_user+0x6c/0x120 [] getname_flags.part.32+0x86/0x150 [] getname+0x3a/0x60 [] sys_symlinkat+0x24/0x90 [] ? tracesys+0x7e/0xe6 [] tracesys+0xe1/0xe6 ---[ end trace 4ba438264ea16e97 ]--- Dave -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx115.postini.com [74.125.245.115]) by kanga.kvack.org (Postfix) with SMTP id 2A7246B0044 for ; Tue, 6 Nov 2012 18:48:25 -0500 (EST) Received: by mail-ie0-f169.google.com with SMTP id 10so1900763ied.14 for ; Tue, 06 Nov 2012 15:48:24 -0800 (PST) Date: Tue, 6 Nov 2012 15:48:20 -0800 (PST) From: Hugh Dickins Subject: Re: [PATCH] tmpfs: fix shmem_getpage_gfp VM_BUG_ON In-Reply-To: <20121106135402.GA3543@redhat.com> Message-ID: References: <20121025023738.GA27001@redhat.com> <20121101191052.GA5884@redhat.com> <20121101232030.GA25519@redhat.com> <20121102014336.GA1727@redhat.com>