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=-9.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_GIT 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 CD402C32751 for ; Wed, 31 Jul 2019 15:59:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id AB23C206A2 for ; Wed, 31 Jul 2019 15:59:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730382AbfGaP7g (ORCPT ); Wed, 31 Jul 2019 11:59:36 -0400 Received: from szxga06-in.huawei.com ([45.249.212.32]:56174 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1729832AbfGaP61 (ORCPT ); Wed, 31 Jul 2019 11:58:27 -0400 Received: from DGGEMS410-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id D86B9402557CD4B6EF46; Wed, 31 Jul 2019 23:58:25 +0800 (CST) Received: from architecture4.huawei.com (10.140.130.215) by smtp.huawei.com (10.3.19.210) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 31 Jul 2019 23:58:19 +0800 From: Gao Xiang To: Greg Kroah-Hartman , Chao Yu , CC: LKML , , "Chao Yu" , Miao Xie , , Fang Wei , Gao Xiang Subject: [PATCH v2 08/22] staging: erofs: kill CONFIG_EROFS_FS_IO_MAX_RETRIES Date: Wed, 31 Jul 2019 23:57:38 +0800 Message-ID: <20190731155752.210602-9-gaoxiang25@huawei.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20190731155752.210602-1-gaoxiang25@huawei.com> References: <20190731155752.210602-1-gaoxiang25@huawei.com> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.140.130.215] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org CONFIG_EROFS_FS_IO_MAX_RETRIES seems a runtime setting and users have no idea about the change in behaviour. Let's remove the setting currently and could turn it into a module parameter if it's really needed. Suggested-by: David Sterba Signed-off-by: Gao Xiang --- drivers/staging/erofs/Kconfig | 9 --------- drivers/staging/erofs/internal.h | 8 ++------ 2 files changed, 2 insertions(+), 15 deletions(-) diff --git a/drivers/staging/erofs/Kconfig b/drivers/staging/erofs/Kconfig index 2577cbb46a5b..747e9eebfaa5 100644 --- a/drivers/staging/erofs/Kconfig +++ b/drivers/staging/erofs/Kconfig @@ -78,15 +78,6 @@ config EROFS_FAULT_INJECTION Test EROFS to inject faults such as ENOMEM, EIO, and so on. If unsure, say N. -config EROFS_FS_IO_MAX_RETRIES - int "EROFS IO Maximum Retries" - depends on EROFS_FS - default "5" - help - Maximum retry count of IO Errors. - - If unsure, leave the default value (5 retries, 6 IOs at most). - config EROFS_FS_ZIP bool "EROFS Data Compresssion Support" depends on EROFS_FS diff --git a/drivers/staging/erofs/internal.h b/drivers/staging/erofs/internal.h index 959bd0ae9d74..a3b9fcdd0c27 100644 --- a/drivers/staging/erofs/internal.h +++ b/drivers/staging/erofs/internal.h @@ -279,6 +279,8 @@ static inline void z_erofs_exit_zip_subsystem(void) {} #error erofs cannot be used in this platform #endif +#define EROFS_IO_MAX_RETRIES_NOFAIL 5 + #define ROOT_NID(sb) ((sb)->root_nid) #define erofs_blknr(addr) ((addr) / EROFS_BLKSIZ) @@ -467,12 +469,6 @@ static inline void __submit_bio(struct bio *bio, unsigned int op, submit_bio(bio); } -#ifndef CONFIG_EROFS_FS_IO_MAX_RETRIES -#define EROFS_IO_MAX_RETRIES_NOFAIL 0 -#else -#define EROFS_IO_MAX_RETRIES_NOFAIL CONFIG_EROFS_FS_IO_MAX_RETRIES -#endif - struct page *__erofs_get_meta_page(struct super_block *sb, erofs_blk_t blkaddr, bool prio, bool nofail); -- 2.17.1 From mboxrd@z Thu Jan 1 00:00:00 1970 From: gaoxiang25@huawei.com (Gao Xiang) Date: Wed, 31 Jul 2019 23:57:38 +0800 Subject: [PATCH v2 08/22] staging: erofs: kill CONFIG_EROFS_FS_IO_MAX_RETRIES In-Reply-To: <20190731155752.210602-1-gaoxiang25@huawei.com> References: <20190731155752.210602-1-gaoxiang25@huawei.com> Message-ID: <20190731155752.210602-9-gaoxiang25@huawei.com> CONFIG_EROFS_FS_IO_MAX_RETRIES seems a runtime setting and users have no idea about the change in behaviour. Let's remove the setting currently and could turn it into a module parameter if it's really needed. Suggested-by: David Sterba Signed-off-by: Gao Xiang --- drivers/staging/erofs/Kconfig | 9 --------- drivers/staging/erofs/internal.h | 8 ++------ 2 files changed, 2 insertions(+), 15 deletions(-) diff --git a/drivers/staging/erofs/Kconfig b/drivers/staging/erofs/Kconfig index 2577cbb46a5b..747e9eebfaa5 100644 --- a/drivers/staging/erofs/Kconfig +++ b/drivers/staging/erofs/Kconfig @@ -78,15 +78,6 @@ config EROFS_FAULT_INJECTION Test EROFS to inject faults such as ENOMEM, EIO, and so on. If unsure, say N. -config EROFS_FS_IO_MAX_RETRIES - int "EROFS IO Maximum Retries" - depends on EROFS_FS - default "5" - help - Maximum retry count of IO Errors. - - If unsure, leave the default value (5 retries, 6 IOs at most). - config EROFS_FS_ZIP bool "EROFS Data Compresssion Support" depends on EROFS_FS diff --git a/drivers/staging/erofs/internal.h b/drivers/staging/erofs/internal.h index 959bd0ae9d74..a3b9fcdd0c27 100644 --- a/drivers/staging/erofs/internal.h +++ b/drivers/staging/erofs/internal.h @@ -279,6 +279,8 @@ static inline void z_erofs_exit_zip_subsystem(void) {} #error erofs cannot be used in this platform #endif +#define EROFS_IO_MAX_RETRIES_NOFAIL 5 + #define ROOT_NID(sb) ((sb)->root_nid) #define erofs_blknr(addr) ((addr) / EROFS_BLKSIZ) @@ -467,12 +469,6 @@ static inline void __submit_bio(struct bio *bio, unsigned int op, submit_bio(bio); } -#ifndef CONFIG_EROFS_FS_IO_MAX_RETRIES -#define EROFS_IO_MAX_RETRIES_NOFAIL 0 -#else -#define EROFS_IO_MAX_RETRIES_NOFAIL CONFIG_EROFS_FS_IO_MAX_RETRIES -#endif - struct page *__erofs_get_meta_page(struct super_block *sb, erofs_blk_t blkaddr, bool prio, bool nofail); -- 2.17.1