Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp564195pxb; Tue, 14 Sep 2021 04:05:13 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyKpc35gYzfC5U0ZNYS+Vm31Cr9WsmeWoC4U5+9v1SBgkh06UcwwuBFORxlDz9XAMl4PpCn X-Received: by 2002:a17:907:2659:: with SMTP id ar25mr1123114ejc.541.1631617513056; Tue, 14 Sep 2021 04:05:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1631617513; cv=none; d=google.com; s=arc-20160816; b=xCroNXfdELMxZFBo2H+WezzBAhTIJGmZTMHIxf7B/L4JqNAuDam1PrKFw4j3RAjX0E ORBvKhws3QhfeQUPcWDNFipbCu7laf9T7zc5RPnj/pPadNu84wHCZAq/tQyoEIq9xQQ9 ZkBNetel8LAYigzXo03UaauaHBwWzyoVXaIUfAHg1iD5szjKjbrztXLYGjIxJWfsXUYC OpHbJHqPc/km6fjNOcA7k2i+dnpR3nLcd6DnW/pHcc7fIP7uSD1zfc761usfewERIN6q yykTyxY3pp746uUernUJZe+M/tV2p6ATzx0M60XTaKdD//Crj1YkYK8yPXKWMgOf57D6 v+4Q== 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 :message-id:date:subject:cc:to:from; bh=iMWFZlIXK1V79eYSjsjgHLyyzUt8VFMCdQBvM+rDwtg=; b=Vi841/yQtzjGFT9bwEQmqCwHinAGY+AALW73DJvv9aabTSOmrQiqGYQgFKJhtUkZzD 1Z9kcTR5bowrzR3TJbY5R7Ox5YK2HXlDSeBn4XFEcrwRCGYM/ZtVv1wZxe9EjqddnXyf +aSmksmMFnhnQhoTCBXEDupIf4kMXC6ym/y66w01a1VbKbg5MjCjOk+i1TkcZjcV8Xq+ kNB6vlBj4lTLvwl7EeA1OYVl0KW4lmjdS+rLtA8AuDQFi3816jcznFch9DpDfeFHxgc8 2Z949J9wSLDXeZcNEDpOkmnRxvY9GsfhilMB1dElMv3aHmIJQU1sDg0uDpuct9yeW8Rf LzVQ== 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 s11si857199ejm.723.2021.09.14.04.04.44; Tue, 14 Sep 2021 04:05:13 -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 S231828AbhINLFl (ORCPT + 99 others); Tue, 14 Sep 2021 07:05:41 -0400 Received: from szxga02-in.huawei.com ([45.249.212.188]:9866 "EHLO szxga02-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231732AbhINLFk (ORCPT ); Tue, 14 Sep 2021 07:05:40 -0400 Received: from dggemv703-chm.china.huawei.com (unknown [172.30.72.57]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4H80jm20yLz8yPL; Tue, 14 Sep 2021 18:59:56 +0800 (CST) Received: from dggema766-chm.china.huawei.com (10.1.198.208) by dggemv703-chm.china.huawei.com (10.3.19.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2308.8; Tue, 14 Sep 2021 19:04:22 +0800 Received: from localhost.localdomain (10.175.127.227) by dggema766-chm.china.huawei.com (10.1.198.208) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.8; Tue, 14 Sep 2021 19:04:21 +0800 From: yangerkun To: , CC: , , Subject: [PATCH] ext4: update last_pos for the case ext4_htree_fill_tree return fail Date: Tue, 14 Sep 2021 19:14:15 +0800 Message-ID: <20210914111415.3921954-1-yangerkun@huawei.com> X-Mailer: git-send-email 2.31.1 MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [10.175.127.227] X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To dggema766-chm.china.huawei.com (10.1.198.208) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org Or the ls for ext4 dir can run into a deadloop since info->last_pos != ctx->pos which will reset the world and start read the entry which has already got before. Details see below: 1. a dx_dir which has 3 block, block 0 as dx_root block, block 1/2 as leaf block which own the ext4_dir_entry_2 2. block 1 read ok and call_filldir which will fill the dirent and update the ctx->pos 3. block 2 read fail, but we has already fill some dirent, so we will return back to userspace will a positive return val(see ksys_getdents64) 4. the second ext4_dx_readdir will reset the world since info->last_pos != ctx->pos, and will also init the curr_hash which pos to block 1 5. So we will read block1 too, and once block2 still read fail, we can only fill one dirent because the hash of the entry in block1(besides the last one) won't greater than curr_hash 6. this time, we forget update last_pos too since the read for block2 will fail, and since we has got the one entry, ksys_getdents64 can return success 7. Latter we will trapped in a loop with step 4~6 Fix it by update last_pos too once ext4_htree_fill_tree return fail. Signed-off-by: yangerkun --- fs/ext4/dir.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/fs/ext4/dir.c b/fs/ext4/dir.c index ffb295aa891c..74b172a4adda 100644 --- a/fs/ext4/dir.c +++ b/fs/ext4/dir.c @@ -551,7 +551,7 @@ static int ext4_dx_readdir(struct file *file, struct dir_context *ctx) struct dir_private_info *info = file->private_data; struct inode *inode = file_inode(file); struct fname *fname; - int ret; + int ret = 0; if (!info) { info = ext4_htree_create_dir_info(file, ctx->pos); @@ -599,7 +599,7 @@ static int ext4_dx_readdir(struct file *file, struct dir_context *ctx) info->curr_minor_hash, &info->next_hash); if (ret < 0) - return ret; + goto finished; if (ret == 0) { ctx->pos = ext4_get_htree_eof(file); break; @@ -630,7 +630,7 @@ static int ext4_dx_readdir(struct file *file, struct dir_context *ctx) } finished: info->last_pos = ctx->pos; - return 0; + return ret < 0 ? ret : 0; } static int ext4_release_dir(struct inode *inode, struct file *filp) -- 2.31.1