Received: by 10.213.65.68 with SMTP id h4csp308397imn; Fri, 16 Mar 2018 03:57:51 -0700 (PDT) X-Google-Smtp-Source: AG47ELvsxxd1FSFAQwpw9tkJaTeeAwmxscwRyUUS8ZJ5b0fMmMIcFcUcjEqFpn/aD9g5y8qvT18O X-Received: by 2002:a17:902:bcc6:: with SMTP id o6-v6mr1632231pls.16.1521197871833; Fri, 16 Mar 2018 03:57:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521197871; cv=none; d=google.com; s=arc-20160816; b=S5ForNJkcmocOST0t+vjYhKNaa0LP9kObTnUUs4nUDVahCLMgcc/CCkcEDZ12e/mMg 2Lv21wYTXiQdoVhSf8P7S2PxkUkyWaHkjNAbEg5RzRq6y4ineYgV5A3wnNwEjtGjMwUg QQOkckXctvUjRu1/LbgCwb+CyVsz7SZN2CECknEjegOKhIqRjUUW7NQdutUXM5m6S5XO ho2iCnORtOdlbtF8JiCE9j2ixKEGQm3dKv5QakZlOU1N+QjAMiVdcS2PEt6aZHNSxyFy /+WnlQ6EMs9HOXCgw3TV2Lstw7Pyui7CMRGSc1B0BWHWLgw2ifNo3/rj4Ziwa3hRaJ7C nGsg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:subject:cc :to:from:arc-authentication-results; bh=nGT0QCN97Hd8WDF5IDkA0DCbnvLt2yJGqsWLfNN/IMs=; b=yW2F5JyazNEFe9xnWn40jaHa05RwAQCU+5kHdihFMJhZf7q7Nt+ULXeC051A1in6bB H30J/FRNF1g2oe713/ami33f48CDp3PiYD0Yq9IyeCZVSnddVs9YdM6hmuIjAMIRqNF7 hZy2JT87mZGsvURE0orD+xrDRjx3geNvBfy4V+ajJWP6UJlmJFrUEPVHVHtuNbVJrbSq EKce1NJGR2yHERGn+iYC+ZLQj/gLQBzhCzbP8irE/7IiTZyfE7CeDR/CHI7silyI5jqY xUkKIIOWxAttrmjHAJ+mKMZdMzlTR/XfE+rHZNq8RJI2x4E2A/jNQQlj6UbND6/IJwcF rEew== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s24-v6si5873704plp.620.2018.03.16.03.57.37; Fri, 16 Mar 2018 03:57:51 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753461AbeCPK4a (ORCPT + 99 others); Fri, 16 Mar 2018 06:56:30 -0400 Received: from szxga06-in.huawei.com ([45.249.212.32]:37119 "EHLO huawei.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1753040AbeCPK43 (ORCPT ); Fri, 16 Mar 2018 06:56:29 -0400 Received: from DGGEMS408-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id 2D3B718A6179A; Fri, 16 Mar 2018 18:56:25 +0800 (CST) Received: from huawei.com (10.175.124.28) by DGGEMS408-HUB.china.huawei.com (10.3.19.208) with Microsoft SMTP Server id 14.3.361.1; Fri, 16 Mar 2018 18:56:16 +0800 From: Yufen Yu To: CC: , , , Yufen Yu Subject: [PATCH] jffs2: remove fd from the f->dents list immediately. Date: Fri, 16 Mar 2018 19:05:22 +0800 Message-ID: <20180316110522.1120-1-yuyufen@huawei.com> X-Mailer: git-send-email 2.13.6 MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.175.124.28] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org commit 15953580e79b ("[JFFS2] Improve getdents vs. f_pos handling on NOR flash.") is introduced to resolve 'rm -r', which cannot remove all files: http://lists.infradead.org/pipermail/linux-mtd/2007-October/019658.html However, it can cause the following issues: 1. 'deletion' dirents is alway in the f->dents list, wasting memory resource. For example: There is a file named 'file1'. Then we rename it: mv file1 file2; mv file2 file3; ... mv file99999 file1000000 When CONFIG_JFFS2_SUMMARY is not set, file1~file1000000 always in the f->dents list. 2. Since the list become longer and longer, more CPU time is used to traverse it. After reverting the commit, we test 'rm -r', which can remove all files, and all seems OK! Signed-off-by: Yufen Yu --- fs/jffs2/write.c | 33 +++++++++++++++++---------------- 1 file changed, 17 insertions(+), 16 deletions(-) diff --git a/fs/jffs2/write.c b/fs/jffs2/write.c index cda9a361368e..1deed35beb50 100644 --- a/fs/jffs2/write.c +++ b/fs/jffs2/write.c @@ -598,31 +598,32 @@ int jffs2_do_unlink(struct jffs2_sb_info *c, struct jffs2_inode_info *dir_f, jffs2_add_fd_to_list(c, fd, &dir_f->dents); mutex_unlock(&dir_f->sem); } else { + struct jffs2_full_dirent **prev = &dir_f->dents; uint32_t nhash = full_name_hash(NULL, name, namelen); - fd = dir_f->dents; /* We don't actually want to reserve any space, but we do want to be holding the alloc_sem when we write to flash */ mutex_lock(&c->alloc_sem); mutex_lock(&dir_f->sem); - for (fd = dir_f->dents; fd; fd = fd->next) { - if (fd->nhash == nhash && - !memcmp(fd->name, name, namelen) && - !fd->name[namelen]) { - - jffs2_dbg(1, "Marking old dirent node (ino #%u) @%08x obsolete\n", - fd->ino, ref_offset(fd->raw)); - jffs2_mark_node_obsolete(c, fd->raw); - /* We don't want to remove it from the list immediately, - because that screws up getdents()/seek() semantics even - more than they're screwed already. Turn it into a - node-less deletion dirent instead -- a placeholder */ - fd->raw = NULL; - fd->ino = 0; - break; + while ((*prev) && (*prev)->nhash <= nhash) { + if ((*prev)->nhash == nhash && + !memcmp((*prev)->name, name, namelen) && + !(*prev)->name[namelen]) { + + struct jffs2_full_dirent *this = *prev; + + jffs2_dbg(1, "Marking old dirent node (ino #%u) @%08x obsolete\n", + this->ino, ref_offset(this->raw)); + *prev = this->next; + jffs2_mark_node_obsolete(c, this->raw); + jffs2_free_full_dirent(this); + + break; } + prev = &((*prev)->next); } + mutex_unlock(&dir_f->sem); } -- 2.13.6