Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp344516imu; Wed, 12 Dec 2018 18:20:13 -0800 (PST) X-Google-Smtp-Source: AFSGD/UAbWk0DrIFFxsHgIAmgR/GJc11SmVH+V+6PK7rDJcmOsbabcY7cGuS9Wke9rKCwsxn4w5K X-Received: by 2002:a63:e055:: with SMTP id n21mr20555909pgj.397.1544667613011; Wed, 12 Dec 2018 18:20:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544667612; cv=none; d=google.com; s=arc-20160816; b=WEnjf0B7p6EmQoAoIHhhgoUIo168IO5F4tMPyzBOp5HqpDaof2fB3qYvPHYEwFx/9J UhfEBCxI45Et4lW44KYRuFZkqWUdUYNyP69MqScmKSpxfYaQM0Tmvldb8yW4MHRAAE6r Xr5rVYBI85ifNTDpoD/Rt3KqsDtCPdKfKQKAdm2sk7+lFvqZbyteFu43FBolOXdaJic/ ELQCBdN4E5KtYJT2kFKlAGCyAnf7O+4oyHGuKdqcOKN3XPTaF9kdv1Is2lsGzYZQ/MFa 1pSWY7LnONYpWqWrvDl7FOmKRVBH+8nOlC84xSXa6VOKNylQQSD8Zq4BsCkTGWTQPJ3v 0OkA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:references:cc:to:from:subject; bh=DN/Gnd1oTIi49sFjZtHMwoFGN1f1amzVZkRvN15Nx7g=; b=LXzRmc1gcvei629oYal9vBtnsMrRZtEVWrR30/eV/KTSYyGTDErJf4yr02xaE5XwiK bSu7sNcXzLNGKJA1oyF+BqSMDuiSzzt4OfAPc0oxYHr9sbDrRQMJdabcQlPSjZwyyOBY lJPCQ4sKh2xsNOLDiV8O4mf+tcepMA+ibbrdjwqV6A/YdsHNYBagTduNUdUZ+R2z//DS F5SHzEORg1dNSONXglwbHR9I8pqZpSfJ9WElIiDWNxJ0Jrn/h+OC1mijyQcJYCgKWlvg D+4jcpksRJCSCDVvyaV28252sy/CewNbNkHuZWDZPqqi2gfrR3EVjjbaXxklAcKqaHw5 lGeQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m30si440647pff.158.2018.12.12.18.19.34; Wed, 12 Dec 2018 18:20:12 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726626AbeLMCS2 (ORCPT + 99 others); Wed, 12 Dec 2018 21:18:28 -0500 Received: from szxga05-in.huawei.com ([45.249.212.191]:15681 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726405AbeLMCS1 (ORCPT ); Wed, 12 Dec 2018 21:18:27 -0500 Received: from DGGEMS405-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id ED07A2F3174ED; Thu, 13 Dec 2018 10:18:21 +0800 (CST) Received: from [127.0.0.1] (10.177.31.14) by DGGEMS405-HUB.china.huawei.com (10.3.19.205) with Microsoft SMTP Server id 14.3.408.0; Thu, 13 Dec 2018 10:18:22 +0800 Subject: Re: [PATCH] squashfs: enable __GFP_FS in ->readpage to prevent hang in mem alloc From: Hou Tao To: CC: , , References: <20181204020840.49576-1-houtao1@huawei.com> <4315acd7-f4b2-b11d-18d8-ab6ce63244b3@huawei.com> Message-ID: <9a6b1897-7b02-09d8-4103-d887a286dda3@huawei.com> Date: Thu, 13 Dec 2018 10:18:21 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <4315acd7-f4b2-b11d-18d8-ab6ce63244b3@huawei.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.31.14] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ping ? On 2018/12/6 9:14, Hou Tao wrote: > ping ? > > On 2018/12/4 10:08, Hou Tao wrote: >> There is no need to disable __GFP_FS in ->readpage: >> * It's a read-only fs, so there will be no dirty/writeback page and >> there will be no deadlock against the caller's locked page >> * It just allocates one page, so compaction will not be invoked >> * It doesn't take any inode lock, so the reclamation of inode will be fine >> >> And no __GFP_FS may lead to hang in __alloc_pages_slowpath() if a >> squashfs page fault occurs in the context of a memory hogger, because >> the hogger will not be killed due to the logic in __alloc_pages_may_oom(). >> >> Signed-off-by: Hou Tao >> --- >> fs/squashfs/file.c | 3 ++- >> fs/squashfs/file_direct.c | 4 +++- >> fs/squashfs/squashfs_fs_f.h | 25 +++++++++++++++++++++++++ >> 3 files changed, 30 insertions(+), 2 deletions(-) >> create mode 100644 fs/squashfs/squashfs_fs_f.h >> >> diff --git a/fs/squashfs/file.c b/fs/squashfs/file.c >> index f1c1430ae721..8603dda4a719 100644 >> --- a/fs/squashfs/file.c >> +++ b/fs/squashfs/file.c >> @@ -51,6 +51,7 @@ >> #include "squashfs_fs.h" >> #include "squashfs_fs_sb.h" >> #include "squashfs_fs_i.h" >> +#include "squashfs_fs_f.h" >> #include "squashfs.h" >> >> /* >> @@ -414,7 +415,7 @@ void squashfs_copy_cache(struct page *page, struct squashfs_cache_entry *buffer, >> TRACE("bytes %d, i %d, available_bytes %d\n", bytes, i, avail); >> >> push_page = (i == page->index) ? page : >> - grab_cache_page_nowait(page->mapping, i); >> + squashfs_grab_cache_page_nowait(page->mapping, i); >> >> if (!push_page) >> continue; >> diff --git a/fs/squashfs/file_direct.c b/fs/squashfs/file_direct.c >> index 80db1b86a27c..a0fdd6215348 100644 >> --- a/fs/squashfs/file_direct.c >> +++ b/fs/squashfs/file_direct.c >> @@ -17,6 +17,7 @@ >> #include "squashfs_fs.h" >> #include "squashfs_fs_sb.h" >> #include "squashfs_fs_i.h" >> +#include "squashfs_fs_f.h" >> #include "squashfs.h" >> #include "page_actor.h" >> >> @@ -60,7 +61,8 @@ int squashfs_readpage_block(struct page *target_page, u64 block, int bsize, >> /* Try to grab all the pages covered by the Squashfs block */ >> for (missing_pages = 0, i = 0, n = start_index; i < pages; i++, n++) { >> page[i] = (n == target_page->index) ? target_page : >> - grab_cache_page_nowait(target_page->mapping, n); >> + squashfs_grab_cache_page_nowait( >> + target_page->mapping, n); >> >> if (page[i] == NULL) { >> missing_pages++; >> diff --git a/fs/squashfs/squashfs_fs_f.h b/fs/squashfs/squashfs_fs_f.h >> new file mode 100644 >> index 000000000000..fc5fb7aeb27d >> --- /dev/null >> +++ b/fs/squashfs/squashfs_fs_f.h >> @@ -0,0 +1,25 @@ >> +/* SPDX-License-Identifier: GPL-2.0 */ >> +#ifndef SQUASHFS_FS_F >> +#define SQUASHFS_FS_F >> + >> +/* >> + * No need to use FGP_NOFS here: >> + * 1. It's a read-only fs, so there will be no dirty/writeback page and >> + * there will be no deadlock against the caller's locked page. >> + * 2. It just allocates one page, so compaction will not be invoked. >> + * 3. It doesn't take any inode lock, so the reclamation of inode >> + * will be fine. >> + * >> + * And GFP_NOFS may lead to infinite loop in __alloc_pages_slowpath() if a >> + * squashfs page fault occurs in the context of a memory hogger, because >> + * the hogger will not be killed due to the logic in __alloc_pages_may_oom(). >> + */ >> +static inline struct page * >> +squashfs_grab_cache_page_nowait(struct address_space *mapping, pgoff_t index) >> +{ >> + return pagecache_get_page(mapping, index, >> + FGP_LOCK|FGP_CREAT|FGP_NOWAIT, >> + mapping_gfp_mask(mapping)); >> +} >> +#endif >> + >> > > > . >