public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Gu Zheng <guz.fnst@cn.fujitsu.com>
To: Kristian Nielsen <knielsen@knielsen-hq.org>
Cc: Dave Jones <davej@redhat.com>, Benjamin LaHaise <bcrl@kvack.org>,
	Kent Overstreet <kmo@daterainc.com>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	Sasha Levin <sasha.levin@oracle.com>
Subject: Re: GPF in aio_migratepage
Date: Mon, 16 Dec 2013 11:27:05 +0800	[thread overview]
Message-ID: <52AE7309.8070108@cn.fujitsu.com> (raw)
In-Reply-To: <52AE6C4A.9080203@cn.fujitsu.com>

Hi Kristian,
On 12/16/2013 10:58 AM, Gu Zheng wrote:

> Hi Kristian,
> On 12/16/2013 05:59 AM, Kristian Nielsen wrote:
> 
>> What is the status of this?
>>
>> If I understand correctly, the crash I saw is different from what Dave
>> saw.

Thought the crash you saw is different from Dave's, but as you know, they
both appear in the compact page path. So this is anther reason that you need
to run with latest Linus' tree or 3.13-rc4 to check again.

Thanks,
Gu

>>
>> There was one patched scheduled for inclusion that fixes Dave's crash. But
>> what about mine? I have been running 3.13-rc2 for a couple of weeks now with
>> your other patch, without seeing it again, which suggests it has helped. But
>> it seems that patch has a locking bug as described by Dave (sleeping under
>> spinlock)? So this appears unsolved as of yet...
>>
>> So I just wanted to check that this was not forgotten. Is there something I
>> can do to help get this sorted out? Should I try to run with unpatched -rc4
>> for some time to check if it appears again? Anything else?
> 
> Thanks for your reminder. I really do not forget this issue.
> This issue seems like a problem that has been fixed yet:
> http://article.gmane.org/gmane.linux.kernel.aio.general/3741/match=potential+use+after+free+aio%5fmigratepage
> commit 5e9ae2e5da0beb93f8557fc92a8f4fbc05ea448f
> aio: fix use-after-free in aio_migratepage
> So I think maybe you can run with latest Linus' tree or 3.13-rc4 to
> check whether this issue still appears.
> Looking forward to your replay.
> 
> Thanks,
> Gu
> 
>>
>>  - Kristian.
>>
>> Dave Jones <davej@redhat.com> writes:
>>
>>> On Mon, Dec 02, 2013 at 06:10:46PM +0800, Gu Zheng wrote:
>>>  > Hi Kristian, Dave,
>>>  > 
>>>  > Could you please help to check whether the following patch can fix this issue?
>>>
>>> This introduces some locking bugs..
>>>
>>>
>>> [  222.327950] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:616
>>> [  222.328004] in_atomic(): 1, irqs_disabled(): 0, pid: 12794, name: trinity-child1
>>> [  222.328044] 1 lock held by trinity-child1/12794:
>>> [  222.328072]  #0:  (&(&mapping->private_lock)->rlock){+.+...}, at: [<ffffffff81210a64>] aio_free_ring+0x44/0x160
>>> [  222.328147] CPU: 1 PID: 12794 Comm: trinity-child1 Not tainted 3.13.0-rc2+ #12 
>>> [  222.328268]  0000000000000268 ffff880229517d68 ffffffff8173bc52 0000000000000000
>>> [  222.328320]  ffff880229517d90 ffffffff8108ad95 ffff880223b6acd0 0000000000000000
>>> [  222.328370]  0000000000000000 ffff880229517e08 ffffffff81741cf3 ffff880229517dc0
>>> [  222.328421] Call Trace:
>>> [  222.328443]  [<ffffffff8173bc52>] dump_stack+0x4e/0x7a
>>> [  222.328475]  [<ffffffff8108ad95>] __might_sleep+0x175/0x200
>>> [  222.328510]  [<ffffffff81741cf3>] mutex_lock_nested+0x33/0x400
>>> [  222.328545]  [<ffffffff81179e68>] unmap_mapping_range+0x68/0x170
>>> [  222.328582]  [<ffffffff81160a35>] truncate_pagecache+0x35/0x60
>>> [  222.328617]  [<ffffffff81160a72>] truncate_setsize+0x12/0x20
>>> [  222.328651]  [<ffffffff81210ab9>] aio_free_ring+0x99/0x160
>>> [  222.328684]  [<ffffffff81213071>] SyS_io_setup+0xef1/0xf00
>>> [  222.328717]  [<ffffffff8174eaa4>] tracesys+0xdd/0xe2
>>>
>>> [  222.328769] ======================================================
>>> [  222.328804] [ INFO: possible circular locking dependency detected ]
>>> [  222.328838] 3.13.0-rc2+ #12 Not tainted
>>> [  222.328862] -------------------------------------------------------
>>> [  222.328896] trinity-child1/12794 is trying to acquire lock:
>>> [  222.328928]  (&mapping->i_mmap_mutex){+.+...}, at: [<ffffffff81179e68>] unmap_mapping_range+0x68/0x170
>>> [  222.328987] 
>>> but task is already holding lock:
>>> [  222.329020]  (&(&mapping->private_lock)->rlock){+.+...}, at: [<ffffffff81210a64>] aio_free_ring+0x44/0x160
>>> [  222.329081] 
>>> which lock already depends on the new lock.
>>>
>>> [  222.329125] 
>>> the existing dependency chain (in reverse order) is:
>>> [  222.329166] 
>>> -> #2 (&(&mapping->private_lock)->rlock){+.+...}:
>>> [  222.329211]        [<ffffffff810af833>] lock_acquire+0x93/0x1c0
>>> [  222.329248]        [<ffffffff817454f0>] _raw_spin_lock+0x40/0x80
>>> [  222.329285]        [<ffffffff811f334d>] __set_page_dirty_buffers+0x2d/0xb0
>>> [  222.331243]        [<ffffffff8115aada>] set_page_dirty+0x3a/0x60
>>> [  222.334437]        [<ffffffff81179a7f>] unmap_single_vma+0x62f/0x830
>>> [  222.337633]        [<ffffffff8117ad19>] unmap_vmas+0x49/0x90
>>> [  222.340819]        [<ffffffff811804bd>] unmap_region+0x9d/0x110
>>> [  222.343968]        [<ffffffff811829f6>] do_munmap+0x226/0x3b0
>>> [  222.346689]        [<ffffffff81182bc4>] vm_munmap+0x44/0x60
>>> [  222.349741]        [<ffffffff81183b42>] SyS_munmap+0x22/0x30
>>> [  222.352758]        [<ffffffff8174eaa4>] tracesys+0xdd/0xe2
>>> [  222.355735] 
>>> -> #1 (&(ptlock_ptr(page))->rlock#2){+.+...}:
>>> [  222.361611]        [<ffffffff810af833>] lock_acquire+0x93/0x1c0
>>> [  222.364589]        [<ffffffff817454f0>] _raw_spin_lock+0x40/0x80
>>> [  222.367200]        [<ffffffff81186338>] __page_check_address+0x98/0x160
>>> [  222.370168]        [<ffffffff811864fe>] page_mkclean+0xfe/0x1c0
>>> [  222.373120]        [<ffffffff8115ad60>] clear_page_dirty_for_io+0x60/0x100
>>> [  222.376076]        [<ffffffff8124d207>] mpage_submit_page+0x47/0x80
>>> [  222.379015]        [<ffffffff8124d350>] mpage_process_page_bufs+0x110/0x130
>>> [  222.381955]        [<ffffffff8124d91b>] mpage_prepare_extent_to_map+0x22b/0x2f0
>>> [  222.384895]        [<ffffffff8125318f>] ext4_writepages+0x4ef/0x1050
>>> [  222.387839]        [<ffffffff8115cdf1>] do_writepages+0x21/0x50
>>> [  222.390786]        [<ffffffff81150959>] __filemap_fdatawrite_range+0x59/0x60
>>> [  222.393747]        [<ffffffff81150a5d>] filemap_write_and_wait_range+0x2d/0x70
>>> [  222.396729]        [<ffffffff812498ca>] ext4_sync_file+0xba/0x4d0
>>> [  222.399714]        [<ffffffff811f1691>] do_fsync+0x51/0x80
>>> [  222.402317]        [<ffffffff811f1980>] SyS_fsync+0x10/0x20
>>> [  222.405240]        [<ffffffff8174eaa4>] tracesys+0xdd/0xe2
>>> [  222.407760] 
>>> -> #0 (&mapping->i_mmap_mutex){+.+...}:
>>> [  222.413349]        [<ffffffff810aed16>] __lock_acquire+0x1786/0x1af0
>>> [  222.416127]        [<ffffffff810af833>] lock_acquire+0x93/0x1c0
>>> [  222.418826]        [<ffffffff81741d37>] mutex_lock_nested+0x77/0x400
>>> [  222.421456]        [<ffffffff81179e68>] unmap_mapping_range+0x68/0x170
>>> [  222.424085]        [<ffffffff81160a35>] truncate_pagecache+0x35/0x60
>>> [  222.426696]        [<ffffffff81160a72>] truncate_setsize+0x12/0x20
>>> [  222.428955]        [<ffffffff81210ab9>] aio_free_ring+0x99/0x160
>>> [  222.431509]        [<ffffffff81213071>] SyS_io_setup+0xef1/0xf00
>>> [  222.434069]        [<ffffffff8174eaa4>] tracesys+0xdd/0xe2
>>> [  222.436308] 
>>> other info that might help us debug this:
>>>
>>> [  222.443857] Chain exists of:
>>>   &mapping->i_mmap_mutex --> &(ptlock_ptr(page))->rlock#2 --> &(&mapping->private_lock)->rlock
>>>
>>> [  222.451618]  Possible unsafe locking scenario:
>>>
>>> [  222.456831]        CPU0                    CPU1
>>> [  222.459413]        ----                    ----
>>> [  222.461958]   lock(&(&mapping->private_lock)->rlock);
>>> [  222.464505]                                lock(&(ptlock_ptr(page))->rlock#2);
>>> [  222.467094]                                lock(&(&mapping->private_lock)->rlock);
>>> [  222.469625]   lock(&mapping->i_mmap_mutex);
>>> [  222.472111] 
>>>  *** DEADLOCK ***
>>>
>>> [  222.478392] 1 lock held by trinity-child1/12794:
>>> [  222.480744]  #0:  (&(&mapping->private_lock)->rlock){+.+...}, at: [<ffffffff81210a64>] aio_free_ring+0x44/0x160
>>> [  222.483240] 
>>> stack backtrace:
>>> [  222.488119] CPU: 1 PID: 12794 Comm: trinity-child1 Not tainted 3.13.0-rc2+ #12 
>>> [  222.493016]  ffffffff824cb110 ffff880229517c30 ffffffff8173bc52 ffffffff824a3f40
>>> [  222.495690]  ffff880229517c70 ffffffff81737fed ffff880229517cc0 ffff8800a1e49d10
>>> [  222.498379]  ffff8800a1e495d0 0000000000000001 0000000000000001 ffff8800a1e49d10
>>> [  222.501073] Call Trace:
>>> [  222.503394]  [<ffffffff8173bc52>] dump_stack+0x4e/0x7a
>>> [  222.506080]  [<ffffffff81737fed>] print_circular_bug+0x200/0x20f
>>> [  222.508781]  [<ffffffff810aed16>] __lock_acquire+0x1786/0x1af0
>>> [  222.511485]  [<ffffffff810af833>] lock_acquire+0x93/0x1c0
>>> [  222.514197]  [<ffffffff81179e68>] ? unmap_mapping_range+0x68/0x170
>>> [  222.516594]  [<ffffffff81179e68>] ? unmap_mapping_range+0x68/0x170
>>> [  222.519307]  [<ffffffff81741d37>] mutex_lock_nested+0x77/0x400
>>> [  222.522028]  [<ffffffff81179e68>] ? unmap_mapping_range+0x68/0x170
>>> [  222.524752]  [<ffffffff81179e68>] ? unmap_mapping_range+0x68/0x170
>>> [  222.527445]  [<ffffffff81179e68>] unmap_mapping_range+0x68/0x170
>>> [  222.530113]  [<ffffffff81160a35>] truncate_pagecache+0x35/0x60
>>> [  222.532785]  [<ffffffff81160a72>] truncate_setsize+0x12/0x20
>>> [  222.535439]  [<ffffffff81210ab9>] aio_free_ring+0x99/0x160
>>> [  222.538089]  [<ffffffff81213071>] SyS_io_setup+0xef1/0xf00
>>> [  222.540725]  [<ffffffff8174eaa4>] tracesys+0xdd/0xe2
>>
> 
> 
> --
> 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/
> 



  reply	other threads:[~2013-12-16  3:34 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
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 [this message]
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=52AE7309.8070108@cn.fujitsu.com \
    --to=guz.fnst@cn.fujitsu.com \
    --cc=bcrl@kvack.org \
    --cc=davej@redhat.com \
    --cc=kmo@daterainc.com \
    --cc=knielsen@knielsen-hq.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox