Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp3208050pxb; Wed, 13 Oct 2021 00:57:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxyhz/jEAocN/wSA3mjryT5qklvAC3fMbtfFpSvo0ssjqnCijTu0l1h6CGiLhJXY3RHY8cH X-Received: by 2002:a05:6402:319a:: with SMTP id di26mr7594995edb.84.1634111832213; Wed, 13 Oct 2021 00:57:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634111832; cv=none; d=google.com; s=arc-20160816; b=wrYry1qCztNH40JCQDDAWhK3wCJ8kD7U0J/I0DtIsVZtABiNV3uYniDRnlyYwywLYF 8c/B4JXjx9Po+ECatINO/ZjEu02rOpEbPZVeBIQhsrNW2cKNPwlXT0CrRzGDFnt7x0Xk egWNsT7jS7Ho/JJoqY92obHWtKsRulxc13EgXOJtJzihh+Our5nMNsq5666rj4gpYckW cgtyKgV49cCeuHTcpjJKfew2a78inXCCZGYuF199SdJXbloJGjCs+E2isURMrfQ16vhn IX5OOkWtv19obidZdX5tz7qseX9R6CcdTtfodZ6Xr1rdbLe3RL09onHfs2/6/gx+iJ7c QfXQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:references :cc:to:from:content-language:subject:user-agent:mime-version:date :message-id; bh=sHh0x3k6oPlcBS+cUASXXneKXuwTTsqebYnStcNOcoc=; b=gtysmeCbzCupBTAmcGRLASekCnRLsUjWm3BqkVffCI0aKjAY/BiegdK2Vwxlkj+Eyo D4i1mWhk8T6LkcBD7vmnCFWMwNzZxO6zDDYUGGExKS2+63mt5Funn4ubm0bpapUOiyT2 KEW7ircWpTZI9B14zYD8hVdQfpRJxbuEDVLqpio9nCB7y5GY2/9x+C2GsE70zWD23DPM fQOe4aEQphDynm6USQpfXq8qIZztF9XvwVPV8pqSt1Y7dltELi4t2A/QJDl6/NKtg1b7 lrWz3/iU2ath16qs5JywaKlO3UoRBcU4P6mdPP1C7UepThdl+dblzw5fyF1eU1fgDy9/ f2fA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id x8si14403632edd.626.2021.10.13.00.56.48; Wed, 13 Oct 2021 00:57:12 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232766AbhJMH5N (ORCPT + 99 others); Wed, 13 Oct 2021 03:57:13 -0400 Received: from out30-42.freemail.mail.aliyun.com ([115.124.30.42]:55620 "EHLO out30-42.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229902AbhJMH5M (ORCPT ); Wed, 13 Oct 2021 03:57:12 -0400 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R601e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04357;MF=rongwei.wang@linux.alibaba.com;NM=1;PH=DS;RN=8;SR=0;TI=SMTPD_---0UrfU4fI_1634111706; Received: from 30.240.98.1(mailfrom:rongwei.wang@linux.alibaba.com fp:SMTPD_---0UrfU4fI_1634111706) by smtp.aliyun-inc.com(127.0.0.1); Wed, 13 Oct 2021 15:55:07 +0800 Message-ID: <60de628a-82dd-24d6-4f89-00a2d61ce628@linux.alibaba.com> Date: Wed, 13 Oct 2021 15:55:05 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:93.0) Gecko/20100101 Thunderbird/93.0 Subject: Re: [PATCH v4 1/2] mm, thp: lock filemap when truncating page cache Content-Language: en-US From: Rongwei Wang To: willy@infradead.org, hughd@google.com, song@kernel.org, shy828301@gmail.com Cc: akpm@linux-foundation.org, william.kucharski@oracle.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20210906121200.57905-1-rongwei.wang@linux.alibaba.com> <20211011022241.97072-1-rongwei.wang@linux.alibaba.com> <20211011022241.97072-2-rongwei.wang@linux.alibaba.com> In-Reply-To: <20211011022241.97072-2-rongwei.wang@linux.alibaba.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello I see this patch has not been replied by all. I'm not sure whether this patch has passed review or the status needs to be modified. Thanks! On 10/11/21 10:22 AM, Rongwei Wang wrote: > Transparent huge page has supported read-only non-shmem files. The file- > backed THP is collapsed by khugepaged and truncated when written (for > shared libraries). > > However, there is a race when multiple writers truncate the same page > cache concurrently. > > In that case, subpage(s) of file THP can be revealed by find_get_entry > in truncate_inode_pages_range, which will trigger PageTail BUG_ON in > truncate_inode_page, as follows. > > page:000000009e420ff2 refcount:1 mapcount:0 mapping:0000000000000000 index:0x7ff pfn:0x50c3ff > head:0000000075ff816d order:9 compound_mapcount:0 compound_pincount:0 > flags: 0x37fffe0000010815(locked|uptodate|lru|arch_1|head) > raw: 37fffe0000000000 fffffe0013108001 dead000000000122 dead000000000400 > raw: 0000000000000001 0000000000000000 00000000ffffffff 0000000000000000 > head: 37fffe0000010815 fffffe001066bd48 ffff000404183c20 0000000000000000 > head: 0000000000000600 0000000000000000 00000001ffffffff ffff000c0345a000 > page dumped because: VM_BUG_ON_PAGE(PageTail(page)) > ------------[ cut here ]------------ > kernel BUG at mm/truncate.c:213! > Internal error: Oops - BUG: 0 [#1] SMP > Modules linked in: xfs(E) libcrc32c(E) rfkill(E) ... > CPU: 14 PID: 11394 Comm: check_madvise_d Kdump: ... > Hardware name: ECS, BIOS 0.0.0 02/06/2015 > pstate: 60400005 (nZCv daif +PAN -UAO -TCO BTYPE=--) > pc : truncate_inode_page+0x64/0x70 > lr : truncate_inode_page+0x64/0x70 > sp : ffff80001b60b900 > x29: ffff80001b60b900 x28: 00000000000007ff > x27: ffff80001b60b9a0 x26: 0000000000000000 > x25: 000000000000000f x24: ffff80001b60b9a0 > x23: ffff80001b60ba18 x22: ffff0001e0999ea8 > x21: ffff0000c21db300 x20: ffffffffffffffff > x19: fffffe001310ffc0 x18: 0000000000000020 > x17: 0000000000000000 x16: 0000000000000000 > x15: ffff0000c21db960 x14: 3030306666666620 > x13: 6666666666666666 x12: 3130303030303030 > x11: ffff8000117b69b8 x10: 00000000ffff8000 > x9 : ffff80001012690c x8 : 0000000000000000 > x7 : ffff8000114f69b8 x6 : 0000000000017ffd > x5 : ffff0007fffbcbc8 x4 : ffff80001b60b5c0 > x3 : 0000000000000001 x2 : 0000000000000000 > x1 : 0000000000000000 x0 : 0000000000000000 > Call trace: > truncate_inode_page+0x64/0x70 > truncate_inode_pages_range+0x550/0x7e4 > truncate_pagecache+0x58/0x80 > do_dentry_open+0x1e4/0x3c0 > vfs_open+0x38/0x44 > do_open+0x1f0/0x310 > path_openat+0x114/0x1dc > do_filp_open+0x84/0x134 > do_sys_openat2+0xbc/0x164 > __arm64_sys_openat+0x74/0xc0 > el0_svc_common.constprop.0+0x88/0x220 > do_el0_svc+0x30/0xa0 > el0_svc+0x20/0x30 > el0_sync_handler+0x1a4/0x1b0 > el0_sync+0x180/0x1c0 > Code: aa0103e0 900061e1 910ec021 9400d300 (d4210000) > ---[ end trace f70cdb42cb7c2d42 ]--- > Kernel panic - not syncing: Oops - BUG: Fatal exception > > This patch mainly to lock filemap when one enter truncate_pagecache(), > avoiding truncating the same page cache concurrently. > > Fixes: eb6ecbed0aa2 ("mm, thp: relax the VM_DENYWRITE constraint on file-backed THPs") > Suggested-by: Matthew Wilcox (Oracle) > Tested-by: Song Liu > Signed-off-by: Xu Yu > Signed-off-by: Rongwei Wang > --- > fs/open.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/fs/open.c b/fs/open.c > index daa324606a41..9ec3cfca3b1a 100644 > --- a/fs/open.c > +++ b/fs/open.c > @@ -856,8 +856,11 @@ static int do_dentry_open(struct file *f, > * of THPs into the page cache will fail. > */ > smp_mb(); > - if (filemap_nr_thps(inode->i_mapping)) > + if (filemap_nr_thps(inode->i_mapping)) { > + filemap_invalidate_lock(inode->i_mapping); > truncate_pagecache(inode, 0); > + filemap_invalidate_unlock(inode->i_mapping); > + } > } > > return 0; >