linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Yisheng Xie <xieyisheng1@huawei.com>
To: Will Deacon <will.deacon@arm.com>,
	chenjiankang <chenjiankang1@huawei.com>
Cc: <catalin.marinas@arm.com>, <linux-kernel@vger.kernel.org>,
	<wangkefeng.wang@huawei.com>
Subject: Re: a racy access flag clearing warning when calling mmap system call
Date: Thu, 7 Dec 2017 09:46:59 +0800	[thread overview]
Message-ID: <3d44f029-7870-f560-786f-f3a55b3ec0c6@huawei.com> (raw)
In-Reply-To: <20171201131832.GB14823@arm.com>

Hi Will,

On 2017/12/1 21:18, Will Deacon wrote:
> On Fri, Dec 01, 2017 at 03:38:04PM +0800, chenjiankang wrote:
>> ------------[ cut here ]------------      
>> WARNING: at ../../../../../kernel/linux-4.1/arch/arm64/include/asm/pgtable.h:211
> 
> Given that this is a fairly old 4.1 kernel, could you try to reproduce the
> failure with something more recent, please? We've fixed many bugs since
> then, some of them involving huge pages.

Yeah, this is and old kernel, but I find a scene that will cause this warn_on:
When fork and dup_mmap, it will call copy_huge_pmd() and clear the Access Flag.
  dup_mmap
    -> copy_page_range
         -> copy_pud_range
              -> copy_pmd_range
                   -> copy_huge_pmd
                        -> pmd_mkold

If we do not have any access after dup_mmap, and start to split this thp,
it will cause this call trace in the old kernel, right?

It seems this is normal scene but will cause call trace for this old kernel,
therefore, for this old kernel, we should just remove this WARN_ON_ONCE, right?

Thanks
Yisheng Xie

> 
> Thanks,
> 
> Will
> 
>> Modules linked in:                         
>> CPU: 0 PID: 3665 Comm: syz-executor7 Not tainted 4.1.44+ #1
>> Hardware name: linux,dummy-virt (DT)       
>> task: ffffffc06a873fc0 ti: ffffffc05aefc000 task.ti: ffffffc05aefc000
>> PC is at pmdp_splitting_flush+0x194/0x1b0
>> LR is at pmdp_splitting_flush+0x194/0x1b0
>> pc : [<ffffffc0000a5244>] lr : [<ffffffc0000a5244>] pstate: 80000145
>> sp : ffffffc05aeff770                     
>> x29: ffffffc05aeff770 x28: ffffffc05ae45800 
>> x27: 0000000020200000 x26: ffffffc061fdf450 
>> x25: 0000000000020000 x24: 0000000000000001 
>> x23: ffffffc06333d9c8 x22: ffffffc0014ba000 
>> x21: 01e000009d200bd1 x20: 00e000009d200bd1 
>> x19: ffffffc05ae45800 x18: 0000000000000000 
>> x17: 00000000004b4000 x16: ffffffc00017fdc0 
>> x15: 00000000038ee280 x14: 3030653130203e2d 
>> x13: 2031646230303264 x12: 3930303030306530 
>> x11: 30203a676e697261 x10: 656c632067616c66 
>> x9 : 2073736563636120 x8 : 79636172203a7461 
>> x7 : ffffffc05aeff430 x6 : ffffffc00015f38c 
>> x5 : 0000000000000003 x4 : 0000000000000000 
>> x3 : 0000000000000003 x2 : 0000000000010000 
>> x1 : ffffff9005a03000 x0 : 000000000000004b 
>> Call trace:                                
>> [<ffffffc0000a5244>] pmdp_splitting_flush+0x194/0x1b0
>> [<ffffffc0002784c0>] split_huge_page_to_list+0x168/0xdb0
>> [<ffffffc00027a0d8>] __split_huge_page_pmd+0x1b0/0x510
>> [<ffffffc00027b5ac>] split_huge_page_pmd_mm+0x84/0x88
>> [<ffffffc00027b674>] split_huge_page_address+0xc4/0xe8
>> [<ffffffc00027b7f4>] __vma_adjust_trans_huge+0x15c/0x190
>> [<ffffffc000238d5c>] vma_adjust+0x884/0x9f0
>> [<ffffffc0002390c8>] __split_vma.isra.5+0x200/0x310
>> [<ffffffc00023b7b8>] do_munmap+0x5e0/0x608 
>> [<ffffffc00023c0d4>] mmap_region+0x12c/0x900
>> [<ffffffc00023cd2c>] do_mmap_pgoff+0x484/0x540
>> [<ffffffc000218118>] vm_mmap_pgoff+0x128/0x158
>> [<ffffffc000239920>] SyS_mmap_pgoff+0x188/0x300
>> [<ffffffc00008cce0>] sys_mmap+0x58/0x80   
>>
> 
> .
> 

  parent reply	other threads:[~2017-12-07  1:47 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-01  7:38 a racy access flag clearing warning when calling mmap system call chenjiankang
2017-12-01 13:18 ` Will Deacon
2017-12-05 12:44   ` chenjiankang
2017-12-07  1:46   ` Yisheng Xie [this message]
2017-12-07 13:23     ` Will Deacon
2017-12-08  3:19       ` chenjiankang
2017-12-08 11:01         ` Catalin Marinas
2017-12-12  3:13           ` chenjiankang

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=3d44f029-7870-f560-786f-f3a55b3ec0c6@huawei.com \
    --to=xieyisheng1@huawei.com \
    --cc=catalin.marinas@arm.com \
    --cc=chenjiankang1@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=wangkefeng.wang@huawei.com \
    --cc=will.deacon@arm.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;
as well as URLs for NNTP newsgroup(s).