From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751089AbdLAHjw (ORCPT ); Fri, 1 Dec 2017 02:39:52 -0500 Received: from szxga04-in.huawei.com ([45.249.212.190]:11463 "EHLO szxga04-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750891AbdLAHjv (ORCPT ); Fri, 1 Dec 2017 02:39:51 -0500 To: , , , , From: chenjiankang Subject: a racy access flag clearing warning when calling mmap system call Message-ID: Date: Fri, 1 Dec 2017 15:38:04 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset="gbk" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.219.158] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.5A21073A.007F,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: fadc1cbb546647f0a36ee3eb78573ffc Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi will I find a warning by a syzkaller test; When the mmap syscall is called to create a virtual memory, firstly it delete a old huge page mapping area; Before splitting the huge page, the pmd of a huge page is set up. But The PTE_AF is zreo belonging to the current pmd of huge page. I suspect that when the child process is created, the PTE_AF is cleared in copy_one_pte(); So, the set_pte_at() can have a warning. There, whether the set_pte_at() should detect PTE_AF? Thanks. The log: set_pte_at: racy access flag clearing: 00e000009d200bd1 -> 01e000009d200bd1 ------------[ cut here ]------------ WARNING: at ../../../../../kernel/linux-4.1/arch/arm64/include/asm/pgtable.h:211 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 : [] lr : [] 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: [] pmdp_splitting_flush+0x194/0x1b0 [] split_huge_page_to_list+0x168/0xdb0 [] __split_huge_page_pmd+0x1b0/0x510 [] split_huge_page_pmd_mm+0x84/0x88 [] split_huge_page_address+0xc4/0xe8 [] __vma_adjust_trans_huge+0x15c/0x190 [] vma_adjust+0x884/0x9f0 [] __split_vma.isra.5+0x200/0x310 [] do_munmap+0x5e0/0x608 [] mmap_region+0x12c/0x900 [] do_mmap_pgoff+0x484/0x540 [] vm_mmap_pgoff+0x128/0x158 [] SyS_mmap_pgoff+0x188/0x300 [] sys_mmap+0x58/0x80