From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 63C18C43461 for ; Thu, 10 Sep 2020 06:26:54 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7FCF3207EA for ; Thu, 10 Sep 2020 06:26:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7FCF3207EA Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=huawei.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A61A66B0068; Thu, 10 Sep 2020 02:26:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A10E96B006C; Thu, 10 Sep 2020 02:26:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 94EDD6B006E; Thu, 10 Sep 2020 02:26:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0117.hostedemail.com [216.40.44.117]) by kanga.kvack.org (Postfix) with ESMTP id 7BF846B0068 for ; Thu, 10 Sep 2020 02:26:50 -0400 (EDT) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 468E8180AD802 for ; Thu, 10 Sep 2020 06:26:50 +0000 (UTC) X-FDA: 77246168580.19.fruit82_2d01981270e3 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin19.hostedemail.com (Postfix) with ESMTP id 16C401AD1B4 for ; Thu, 10 Sep 2020 06:26:50 +0000 (UTC) X-HE-Tag: fruit82_2d01981270e3 X-Filterd-Recvd-Size: 3442 Received: from huawei.com (szxga03-in.huawei.com [45.249.212.189]) by imf31.hostedemail.com (Postfix) with ESMTP for ; Thu, 10 Sep 2020 06:26:49 +0000 (UTC) Received: from dggeme703-chm.china.huawei.com (unknown [172.30.72.53]) by Forcepoint Email with ESMTP id 885AF6857F474B3979AB; Thu, 10 Sep 2020 14:26:45 +0800 (CST) Received: from dggeme753-chm.china.huawei.com (10.3.19.99) by dggeme703-chm.china.huawei.com (10.1.199.99) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Thu, 10 Sep 2020 14:26:45 +0800 Received: from dggeme753-chm.china.huawei.com ([10.7.64.70]) by dggeme753-chm.china.huawei.com ([10.7.64.70]) with mapi id 15.01.1913.007; Thu, 10 Sep 2020 14:26:45 +0800 From: linmiaohe To: Hillf Danton CC: Souptick Joarder , syzbot , Andrew Morton , "linux-kernel@vger.kernel.org" , Linux-MM , "syzkaller-bugs@googlegroups.com" Subject: Re: general protection fault in unlink_file_vma Thread-Topic: general protection fault in unlink_file_vma Thread-Index: AdaHOf7o7TdygKeMkk6oouf0he4T3A== Date: Thu, 10 Sep 2020 06:26:45 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.174.178.74] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Rspamd-Queue-Id: 16C401AD1B4 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam03 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hillf Danton wrote: >> On Thu, 10 Sep 2020 07:43:41 +0530 Souptick Joarder wrote: >> On Wed, Sep 9, 2020 at 9:45 AM Hillf Danton wrote: >> > Tue, 08 Sep 2020 17:19:17 -0700 >> > > syzbot found the following issue on: >> > > >> > > HEAD commit: 59126901 Merge tag 'perf-tools-fixes-for-v5.9-2020-0= 9-03' .. >> > >> > Looks like d70cec898324 ("mm: mmap: merge vma after call_mmap() if=20 >> > possible") added an extra fput. >>=20 >> Can you please help me to understand how do you figure out this commit ? > >Feel free to correct Hillf if I missed any thing. >Failing to reproduce the gpf without the commit may tell us more about it = than I could. >> > >> > --- a/mm/mmap.c >> > +++ b/mm/mmap.c >> > @@ -1781,7 +1781,6 @@ unsigned long mmap_region(struct file *f >> > merge =3D vma_merge(mm, prev, vma->vm_start, v= ma->vm_end, vma->vm_flags, >> > NULL, vma->vm_file, vma->vm_pgoff, NUL= L, NULL_VM_UFFD_CTX); >> > if (merge) { >> > - fput(file); >> > vm_area_free(vma); >> > vma =3D merge; >> > /* Update vm_flags and possible addr=20 >> > to pick up the change. We don't Yes, It seems vma_merge() could fput the vm_file via remove_next case in __= vma_adjust(). So the fput vm_file here do the extra one. But we may not remove the fput here directly as vma_merge() do not always f= put the vm_file. I'am not really familiar with the vma merge yet, but I would try my best to fix this as soon as possible. Many thanks for point this out. And sorry for my careless.