Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp3898947pxf; Tue, 16 Mar 2021 00:01:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwhKv3JZSwIUgI+SPTKRYQ1i7dGhReNAj/+GYf1O+7XSd1Fh02VyCt8dDQQlrLS5qWB0Xo8 X-Received: by 2002:a05:6402:3596:: with SMTP id y22mr34470374edc.207.1615878063167; Tue, 16 Mar 2021 00:01:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1615878063; cv=none; d=google.com; s=arc-20160816; b=jV+Ddza8pPEexi3mJhYo2cyEbXO2B4bcmLQXU47MnWSjipNi5x8AcmfMpFCBksQXME m2BVKFjSDLYFN8h1kWqbYw1p3zuJTdgQ+nKy29RZc7XZfkLc2GW9wM8VyDUBWhRMzBcW cyzzUmE2GLvJykhRp2mgrmm8389FTL8A+vUDeYEAx+pMWNPVCOHXBE4aD5CiyW4LRSDy 4ne6g0po6Idj9W+p8XRhopZpkk5m0EoWFM9FEfgOec7V9qFY4ACD++8ZkOeu0yL1G92W gp5l5zSbwclFEHgGc5W2Z4TjoobxXVCzgJnAoLj2GkOrirJIRbx1xLhOKHOBLzSNkIWY WHhA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=2vEy44yPsXTENHu/Cm/u2XGem85fHdcAdvtFSxt0PN8=; b=vooLSNNABVTI6VPiKr3qn1aRYWHUR6tNzns8CLpi3RX9K3DkJGS4oLRy8aZbdMuVw3 mPZ0k7EKzYK/O+Qt1baIojRZlSCOyI65i8SGPOTw0nKj4b/4ObhZnE0LElEHvqr8knpa l1rHdf1Vs8kV7nOIDxfukEczUq/a84hcfM+/QK8Q2ZFaERRrAv2KKr4+jAOz4eOuAC8z Ip+wv3vdMigpKsiQoM5tazQGbq0XYOtCIKcxT9GHkWjxC+8DslwlAKVHsSbtUqOq3+f1 ReOS0bYCKsA6rr53xFUXlBDFSPi7W0gd83UWq6dYjSUuUMyGiTF2QwSEZVv5rOUFjdNz TwlQ== 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=huawei.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z18si12844606ejx.409.2021.03.16.00.00.40; Tue, 16 Mar 2021 00:01:03 -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=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230211AbhCPBLM (ORCPT + 99 others); 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); >