Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp319515pxb; Wed, 18 Aug 2021 23:48:29 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzSyHg3RE+G6GVuRZcleLu8o3wfB+g17Bu+0AHmzqJ9ybRqQs9dFbRUNLpD130Bl41FbKvQ X-Received: by 2002:a05:6602:2ac7:: with SMTP id m7mr10441128iov.66.1629355709523; Wed, 18 Aug 2021 23:48:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1629355709; cv=none; d=google.com; s=arc-20160816; b=LEILUtVm3jGR5YCaxl06n+oJ37ZmMESFexiSw02hhIArc7f9YwliwqY/uYH0X0kqMS nfwor/dNe8mdO8OqTsy6DrMDSBA/VI56HHJyeLxLGLXcKxkGSorRSX/knN5sl1RMYIoN YA3NwG+fz8dhPe6RLu85KfLQTpTiYnOZpQe3bwzre8nnO2LzzI4BLBUiL88QLFYMiTmd i8ji24DUekBYJEB6za7QRB+aHdcxRjM3fTnWXTr4R4qbh0JUDLShkewNzH6rYqrIRV7m WdabPFDZR1D4rfb0njL7Mh2dJe3fIkybxMpVumJl1p9ddQn9NK7yUblMsXvE3HRMSqrS Wwfg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=tQ6HxLb3MpYKvliV2q4KLKhOwUjD/m1c2Qjj2f7gHnU=; b=tagAMrgVWLqXhxiMWqr3HI+9H5NIj/5a7MHEXTxYu7/bI4SSuXUNoGH37krE1de/0C JHeCyLbxJ4R3Akd0WjdvAiv8od6YU+J3SL2OvuS3piUTnoWS+3+q0weRucdiH+e7kTpn HKj3Fi8eaC3vLOZ5fImBTM5+BIaLZ5NyOXUuoJHDDmyT+KOV11z6zX6b4kWylkyDkmfM rZv+X5FAZzrA0poEjzu18g4B5ZvIl8CTnmsU9zzWXUVtIFMPm/Q8TiTYprV28YcnzuaE cjNBjHLzeCXZ4lQHtThh7iEwywXRwlrJVcrLJ2Jh0in4k3IMP2lFkjcP/uSi6tPHxVwU bNMg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-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 b16si2086393ior.73.2021.08.18.23.48.16; Wed, 18 Aug 2021 23:48:29 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-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-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-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 S231234AbhHSGrO (ORCPT + 99 others); Thu, 19 Aug 2021 02:47:14 -0400 Received: from szxga01-in.huawei.com ([45.249.212.187]:8043 "EHLO szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231294AbhHSGrN (ORCPT ); Thu, 19 Aug 2021 02:47:13 -0400 Received: from dggeme752-chm.china.huawei.com (unknown [172.30.72.57]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4GqwJy2fSdzYqdQ; Thu, 19 Aug 2021 14:46:10 +0800 (CST) Received: from huawei.com (10.175.127.227) by dggeme752-chm.china.huawei.com (10.3.19.98) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Thu, 19 Aug 2021 14:46:35 +0800 From: Zhang Yi To: CC: , , , , Subject: [PATCH v2 3/4] ext4: don't return error if huge_file feature mismatch Date: Thu, 19 Aug 2021 14:57:03 +0800 Message-ID: <20210819065704.1248402-4-yi.zhang@huawei.com> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210819065704.1248402-1-yi.zhang@huawei.com> References: <20210819065704.1248402-1-yi.zhang@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [10.175.127.227] X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To dggeme752-chm.china.huawei.com (10.3.19.98) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org In ext4_inode_blocks_set(), huge_file feature should exist when setting i_blocks beyond a 32 bit variable could be represented, return EFBIG if not. This error should never happen in theory since sb->s_maxbytes should not have allowed this, and we have already init sb->s_maxbytes according to this feature in ext4_fill_super(). So switch to use WARN_ON_ONCE instead. Signed-off-by: Zhang Yi --- fs/ext4/inode.c | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index eae1b2d0b550..d0d7a5295bf9 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -4902,9 +4902,9 @@ struct inode *__ext4_iget(struct super_block *sb, unsigned long ino, return ERR_PTR(ret); } -static int ext4_inode_blocks_set(handle_t *handle, - struct ext4_inode *raw_inode, - struct ext4_inode_info *ei) +static void ext4_inode_blocks_set(handle_t *handle, + struct ext4_inode *raw_inode, + struct ext4_inode_info *ei) { struct inode *inode = &(ei->vfs_inode); u64 i_blocks = READ_ONCE(inode->i_blocks); @@ -4918,10 +4918,15 @@ static int ext4_inode_blocks_set(handle_t *handle, raw_inode->i_blocks_lo = cpu_to_le32(i_blocks); raw_inode->i_blocks_high = 0; ext4_clear_inode_flag(inode, EXT4_INODE_HUGE_FILE); - return 0; + return; } - if (!ext4_has_feature_huge_file(sb)) - return -EFBIG; + + /* + * This should never happen since sb->s_maxbytes should not have + * allowed this, which was set according to the huge_file feature + * in ext4_fill_super(). + */ + WARN_ON_ONCE(!ext4_has_feature_huge_file(sb)); if (i_blocks <= 0xffffffffffffULL) { /* @@ -4938,7 +4943,6 @@ static int ext4_inode_blocks_set(handle_t *handle, raw_inode->i_blocks_lo = cpu_to_le32(i_blocks); raw_inode->i_blocks_high = cpu_to_le16(i_blocks >> 32); } - return 0; } static void __ext4_update_other_inode_time(struct super_block *sb, @@ -5029,11 +5033,7 @@ static int ext4_do_update_inode(handle_t *handle, if (ext4_test_inode_state(inode, EXT4_STATE_NEW)) memset(raw_inode, 0, EXT4_SB(inode->i_sb)->s_inode_size); - err = ext4_inode_blocks_set(handle, raw_inode, ei); - if (err) { - spin_unlock(&ei->i_raw_lock); - goto out_brelse; - } + ext4_inode_blocks_set(handle, raw_inode, ei); raw_inode->i_mode = cpu_to_le16(inode->i_mode); i_uid = i_uid_read(inode); -- 2.31.1