| 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
| ||
|
Date: Mon, 16 Dec 2013 10:58:18 +0800
From: Gu Zheng <guz.fnst@...fujitsu.com>
To: Kristian Nielsen <knielsen@...elsen-hq.org>
CC: Dave Jones <davej@...hat.com>, Benjamin LaHaise <bcrl@...ck.org>,
Kent Overstreet <kmo@...erainc.com>,
Linux Kernel <linux-kernel@...r.kernel.org>,
Sasha Levin <sasha.levin@...cle.com>
Subject: Re: GPF in aio_migratepage
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.
>
> 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@...hat.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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists