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=-15.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=unavailable 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 B44F8C433E0 for ; Tue, 16 Mar 2021 01:11:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 818DE64F50 for ; Tue, 16 Mar 2021 01:11:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231915AbhCPBLM (ORCPT ); Mon, 15 Mar 2021 21:11:12 -0400 Received: from szxga05-in.huawei.com ([45.249.212.191]:13539 "EHLO szxga05-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229728AbhCPBLI (ORCPT ); Mon, 15 Mar 2021 21:11:08 -0400 Received: from DGGEMS408-HUB.china.huawei.com (unknown [172.30.72.58]) by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4DzwCb2v1nzPjn8; Tue, 16 Mar 2021 09:08:43 +0800 (CST) Received: from [10.136.110.154] (10.136.110.154) by smtp.huawei.com (10.3.19.208) with Microsoft SMTP Server (TLS) id 14.3.498.0; Tue, 16 Mar 2021 09:11:03 +0800 Subject: Re: [PATCH v5 1/2] erofs: avoid memory allocation failure during rolling decompression To: Huang Jianan CC: , , , References: <20210305062219.557128-1-huangjianan@oppo.com> <20210305095840.31025-1-huangjianan@oppo.com> From: Chao Yu Message-ID: <110aa688-515d-7569-80fc-546bbeedc8c5@huawei.com> Date: Tue, 16 Mar 2021 09:11:02 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20210305095840.31025-1-huangjianan@oppo.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.136.110.154] X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2021/3/5 17:58, Huang Jianan via Linux-erofs wrote: > Currently, err would be treated as io error. Therefore, it'd be > better to ensure memory allocation during rolling decompression > to avoid such io error. > > In the long term, we might consider adding another !Uptodate case > for such case. > > Signed-off-by: Huang Jianan > Signed-off-by: Guo Weichao > --- > fs/erofs/decompressor.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/fs/erofs/decompressor.c b/fs/erofs/decompressor.c > index 1cb1ffd10569..3d276a8aad86 100644 > --- a/fs/erofs/decompressor.c > +++ b/fs/erofs/decompressor.c > @@ -73,7 +73,8 @@ static int z_erofs_lz4_prepare_destpages(struct z_erofs_decompress_req *rq, > victim = availables[--top]; > get_page(victim); > } else { > - victim = erofs_allocpage(pagepool, GFP_KERNEL); > + victim = erofs_allocpage(pagepool, > + GFP_KERNEL | __GFP_NOFAIL); > if (!victim) > return -ENOMEM; A little bit weird that we still need to check return value of erofs_allocpage() after we pass __GFP_NOFAIL parameter. Thanks, > set_page_private(victim, Z_EROFS_SHORTLIVED_PAGE); > 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=-15.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=ham 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 582BAC433DB for ; Tue, 16 Mar 2021 01:11:21 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id BCF3C64F6D for ; Tue, 16 Mar 2021 01:11:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BCF3C64F6D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=huawei.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linux-erofs-bounces+linux-erofs=archiver.kernel.org@lists.ozlabs.org Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4DzwGb3pBHz30Md for ; Tue, 16 Mar 2021 12:11:19 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=huawei.com (client-ip=45.249.212.191; helo=szxga05-in.huawei.com; envelope-from=yuchao0@huawei.com; receiver=) Received: from szxga05-in.huawei.com (szxga05-in.huawei.com [45.249.212.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4DzwGR1cGCz30GG for ; Tue, 16 Mar 2021 12:11:10 +1100 (AEDT) Received: from DGGEMS408-HUB.china.huawei.com (unknown [172.30.72.58]) by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4DzwCb2v1nzPjn8; Tue, 16 Mar 2021 09:08:43 +0800 (CST) Received: from [10.136.110.154] (10.136.110.154) by smtp.huawei.com (10.3.19.208) with Microsoft SMTP Server (TLS) id 14.3.498.0; Tue, 16 Mar 2021 09:11:03 +0800 Subject: Re: [PATCH v5 1/2] erofs: avoid memory allocation failure during rolling decompression To: Huang Jianan References: <20210305062219.557128-1-huangjianan@oppo.com> <20210305095840.31025-1-huangjianan@oppo.com> From: Chao Yu Message-ID: <110aa688-515d-7569-80fc-546bbeedc8c5@huawei.com> Date: Tue, 16 Mar 2021 09:11:02 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20210305095840.31025-1-huangjianan@oppo.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.136.110.154] X-CFilter-Loop: Reflected X-BeenThere: linux-erofs@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Development of Linux EROFS file system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: zhangshiming@oppo.com, linux-erofs@lists.ozlabs.org, guoweichao@oppo.com, linux-kernel@vger.kernel.org Errors-To: linux-erofs-bounces+linux-erofs=archiver.kernel.org@lists.ozlabs.org Sender: "Linux-erofs" On 2021/3/5 17:58, Huang Jianan via Linux-erofs wrote: > Currently, err would be treated as io error. Therefore, it'd be > better to ensure memory allocation during rolling decompression > to avoid such io error. > > In the long term, we might consider adding another !Uptodate case > for such case. > > Signed-off-by: Huang Jianan > Signed-off-by: Guo Weichao > --- > fs/erofs/decompressor.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/fs/erofs/decompressor.c b/fs/erofs/decompressor.c > index 1cb1ffd10569..3d276a8aad86 100644 > --- a/fs/erofs/decompressor.c > +++ b/fs/erofs/decompressor.c > @@ -73,7 +73,8 @@ static int z_erofs_lz4_prepare_destpages(struct z_erofs_decompress_req *rq, > victim = availables[--top]; > get_page(victim); > } else { > - victim = erofs_allocpage(pagepool, GFP_KERNEL); > + victim = erofs_allocpage(pagepool, > + GFP_KERNEL | __GFP_NOFAIL); > if (!victim) > return -ENOMEM; A little bit weird that we still need to check return value of erofs_allocpage() after we pass __GFP_NOFAIL parameter. Thanks, > set_page_private(victim, Z_EROFS_SHORTLIVED_PAGE); >