All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin LaHaise <bcrl@kvack.org>
To: Kent Overstreet <kmo@daterainc.com>
Cc: Dave Jones <davej@redhat.com>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	Sasha Levin <sasha.levin@oracle.com>
Subject: Re: GPF in aio_migratepage
Date: Tue, 26 Nov 2013 10:23:37 -0500	[thread overview]
Message-ID: <20131126152337.GL15489@kvack.org> (raw)
In-Reply-To: <20131126071953.GE9244@kmo-pixel>

On Mon, Nov 25, 2013 at 11:19:53PM -0800, Kent Overstreet wrote:
> On Tue, Nov 26, 2013 at 01:01:32AM -0500, Dave Jones wrote:
> > On Mon, Nov 25, 2013 at 10:26:45PM -0500, Dave Jones wrote:
> >  > Hi Kent,
> >  > 
> >  > I hit the GPF below on a tree based on 8e45099e029bb6b369b27d8d4920db8caff5ecce
> >  > which has your commit e34ecee2ae791df674dfb466ce40692ca6218e43
> >  > ("aio: Fix a trinity splat").  Is this another path your patch missed, or
> >  > a completely different bug to what you were chasing ?
> > 
> > And here's another from a different path, this time on 32bit.

For Dave: what line is this bug on?  Is it the dereference of ctx when 
doing spin_lock_irqsave(&ctx->completion_lock, flags); or is the 
ctx->ring_pages[idx] = new; ?  From the 64 bit splat, I'm thinking the 
former, which is quite strange given that the clearing of 
mapping->private_data is protected by mapping->private_lock.  If it's 
the latter, we might well need to check if ctx->ring_pages is NULL during 
setup. 

Actually, is there easy way to reproduce this with Trinity?  I can have a 
look if you point me in the right direction.

> I'm pretty sure this is a different bug... it appears to be related to
> aio ring buffer migration, which I don't think I've touched.
> 
> Any information on what it was doing at the time? I see exit_aio() in
> the second backtrace, maybe some sort of race between migratepage and
> ioctx teardown? But it is using the address space mapping, so I dunno.

Teardown should be protected by mapping->private_lock (see put_aio_ring_file() 
which takes mapping->private_lock to protect aio_migratepage() against 
accessing the ioctx after releasing the private file for the mapping.

		-ben

> I don't see what's protecting ctx->ring_pages - I imagine it's got to
> have something to do with the page migration machinery but I have no
> idea how that works. Ben?
> > ESI: f68dc508 EDI: deaf4800 EBP: dea23bcc ESP: dea23ba8
> >  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
> > CR0: 8005003b CR2: 6b6b707b CR3: 2c985000 CR4: 000007f0
> > Stack:
> >  00000000 00000001 deaf4a84 00000286 d709b280 00000000 f68dc508 c11c7955
> >  f6844ed8 dea23c0c c116aa9f 00000001 00000001 c11c7955 c1179a33 00000000
> >  00000000 c114166d f6844ed8 f6844ed8 c1140fc9 dea23c0c 00000000 f6844ed8
> > Call Trace:
> >  [<c11c7955>] ? free_ioctx+0x62/0x62
> >  [<c116aa9f>] move_to_new_page+0x63/0x1bb
> >  [<c11c7955>] ? free_ioctx+0x62/0x62
> >  [<c1179a33>] ? mem_cgroup_prepare_migration+0xc1/0x243
> >  [<c114166d>] ? isolate_migratepages_range+0x3fb/0x675
> >  [<c1140fc9>] ? isolate_freepages_block+0x316/0x316
> >  [<c116b319>] migrate_pages+0x614/0x72b
> >  [<c1140fc9>] ? isolate_freepages_block+0x316/0x316
> >  [<c1141c21>] compact_zone+0x294/0x475
> >  [<c1142065>] try_to_compact_pages+0x129/0x196
> >  [<c15b95e7>] __alloc_pages_direct_compact+0x91/0x197
> >  [<c112a25c>] __alloc_pages_nodemask+0x863/0xa55
> >  [<c116b68f>] get_huge_zero_page+0x52/0xf9
> >  [<c116ef78>] do_huge_pmd_anonymous_page+0x24e/0x39f
> >  [<c1171c4b>] ? __mem_cgroup_count_vm_event+0xa6/0x191
> >  [<c1171c64>] ? __mem_cgroup_count_vm_event+0xbf/0x191
> >  [<c114815c>] handle_mm_fault+0x235/0xd9a
> >  [<c15c7586>] ? __do_page_fault+0xf8/0x5a1
> >  [<c15c75ee>] __do_page_fault+0x160/0x5a1
> >  [<c15c7586>] ? __do_page_fault+0xf8/0x5a1
> >  [<c15c7a2f>] ? __do_page_fault+0x5a1/0x5a1
> >  [<c15c7a3c>] do_page_fault+0xd/0xf
> >  [<c15c4e7c>] error_code+0x6c/0x74
> >  [<c114007b>] ? memcg_update_all_caches+0x23/0x6b
> >  [<c12d0be5>] ? __copy_from_user_ll+0x30/0xdb
> >  [<c12d0ccf>] _copy_from_user+0x3f/0x55
> >  [<c1057aa2>] SyS_setrlimit+0x27/0x50
> >  [<c1044792>] ? SyS_gettimeofday+0x33/0x6d
> >  [<c12d0798>] ? trace_hardirqs_on_thunk+0xc/0x10
> >  [<c15cb33b>] sysenter_do_call+0x12/0x32
> > Code: 6e 8d 8f 84 02 00 00 89 c8 89 4d e4 e8 df bf 3f 00 89 45 e8 89 da 89 f0 e8 99 2b fa ff 8b 43 08 3b 47 54 8b 4d e4 73 06 8b 57 50 <89> 34 82 8b 55 e8 89 c8 e8 aa c1 3f 00 8b 45 ec e8 28 c1 3f 00
> > 

-- 
"Thought is the essence of where you are now."

  reply	other threads:[~2013-11-26 15:23 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-26  3:26 GPF in aio_migratepage Dave Jones
2013-11-26  6:01 ` Dave Jones
2013-11-26  7:19   ` Kent Overstreet
2013-11-26 15:23     ` Benjamin LaHaise [this message]
2013-11-26 15:56       ` Dave Jones
2013-12-03  9:02         ` Gu Zheng
2013-11-30 15:28       ` Kristian Nielsen
2013-12-02 10:10         ` Gu Zheng
2013-12-02 10:49           ` Kristian Nielsen
2013-12-02 17:49           ` Dave Jones
2013-12-15 21:59             ` Kristian Nielsen
2013-12-16  2:58               ` Gu Zheng
2013-12-16  3:27                 ` Gu Zheng
2013-12-22 20:44                 ` Kristian Nielsen
2013-12-22 21:34                   ` Benjamin LaHaise
2013-12-22 22:38                     ` Kristian Nielsen
2014-01-21  8:38                       ` Kristian Nielsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131126152337.GL15489@kvack.org \
    --to=bcrl@kvack.org \
    --cc=davej@redhat.com \
    --cc=kmo@daterainc.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sasha.levin@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.