Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp1744533pxf; Fri, 12 Mar 2021 18:56:50 -0800 (PST) X-Google-Smtp-Source: ABdhPJzlfIOSww1zLfmJuUZs2phWAIX3cpIG8pn9Re/bX5VVSqq4GSYswhNeebDxXCUauRCox2gz X-Received: by 2002:a17:906:d0c3:: with SMTP id bq3mr11659335ejb.424.1615604210659; Fri, 12 Mar 2021 18:56:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1615604210; cv=none; d=google.com; s=arc-20160816; b=P4UMl+DXq4XdCIzvVchFw6Uf8Er5p9q85ouemH9/71r7McoiGMoCO9uZtFHTOSNTQf JY+8/L7n9vTgzX1hbUWR+oQZYeZmFBWFEP/HI+7CMS5rZR5xQDdLWt4l8SjWswK78oL1 YoXC905O9hkc5P6KNQkKLfeOqZNGUc2+xIxV1ZnKbZrYtTXTYu0+RUmqfoaAte8jMU50 q9aQWNB8l8gUzuXTA0lLu7d79J/op2nR0UXuSIfqU8PIf3QaHezQXLTlgfFjlsls9UQE GWpKU0pAFF6ZI2pVuHpc/JMQeP32zKS/8yC9wfvyICXX7BzPgaNVOpDJTqSeEfp4mJjF PITQ== 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=W6i4wRuXj1opCqyUF154CT1NDdUtvEDd8JT9hMApD9k=; b=KKzVAEal9V+mbnlpBLjViKb2qC+yc6pFJ2wthVSmiv082cAfovX4QjgxVLxuG01GAv q9UKVrvtYJb5yrvmdh2zh/T9MnItPrBrl8UYgVYxLe7UQOXgratCdqq828MoeoNm7hN7 QzCZm3b0unDvmo+NaKn03ifGV3g0k8MW8GqQuKtSj6hhcszhm/EngMnTAA1u44g6QzIJ ktVAct86vaG3EMF97aYVw5ebGeTV9LlYn1fQRG7iCU3HfRM5sTEOg7aM0GWONhC/ZI6t k3AcnRyAldUVgIOzyq8b3smj/qpwaUkysoDtoSGLN0R/yzkbhn6xibQhDO6lYYFbfsXc JoMg== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k19si5522539eja.265.2021.03.12.18.56.27; Fri, 12 Mar 2021 18:56:50 -0800 (PST) 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232602AbhCMCzk (ORCPT + 99 others); Fri, 12 Mar 2021 21:55:40 -0500 Received: from szxga07-in.huawei.com ([45.249.212.35]:14325 "EHLO szxga07-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232559AbhCMCzH (ORCPT ); Fri, 12 Mar 2021 21:55:07 -0500 Received: from DGGEMS413-HUB.china.huawei.com (unknown [172.30.72.60]) by szxga07-in.huawei.com (SkyGuard) with ESMTP id 4Dy6gc0hc3z8wSM; Sat, 13 Mar 2021 10:53:16 +0800 (CST) Received: from huawei.com (10.175.127.227) by DGGEMS413-HUB.china.huawei.com (10.3.19.213) with Microsoft SMTP Server id 14.3.498.0; Sat, 13 Mar 2021 10:54:57 +0800 From: "zhangyi (F)" To: , , , CC: , , , , , , , Subject: [RFC PATCH 1/3] block_dump: remove block_dump feature in mark_inode_dirty() Date: Sat, 13 Mar 2021 11:01:44 +0800 Message-ID: <20210313030146.2882027-2-yi.zhang@huawei.com> X-Mailer: git-send-email 2.25.4 In-Reply-To: <20210313030146.2882027-1-yi.zhang@huawei.com> References: <20210313030146.2882027-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-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org block_dump is an old debugging interface, one of it's functions is used to print the information about who write which file on disk. If we enable block_dump through /proc/sys/vm/block_dump and turn on debug log level, we can gather information about write process name, target file name and disk from kernel message. This feature is realized in block_dump___mark_inode_dirty(), it print above information into kernel message directly when marking inode dirty, so it is noisy and can easily trigger log storm. At the same time, get the dentry refcount is also not safe, we found it will lead to deadlock on ext4 file system with data=journal mode. After tracepoints has been introduced into the kernel, we got a tracepoint in __mark_inode_dirty(), which is a better replacement of block_dump___mark_inode_dirty(). The only downside is that it only trace the inode number and not a file name, but it probably doesn't matter because the original printed file name in block_dump is not accurate in some cases, and we can still find it through the inode number and device id. So this patch delete the dirting inode part of block_dump feature. Signed-off-by: zhangyi (F) --- fs/fs-writeback.c | 25 ------------------------- 1 file changed, 25 deletions(-) diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c index e91980f49388..7c46d1588a19 100644 --- a/fs/fs-writeback.c +++ b/fs/fs-writeback.c @@ -2205,28 +2205,6 @@ int dirtytime_interval_handler(struct ctl_table *table, int write, return ret; } -static noinline void block_dump___mark_inode_dirty(struct inode *inode) -{ - if (inode->i_ino || strcmp(inode->i_sb->s_id, "bdev")) { - struct dentry *dentry; - const char *name = "?"; - - dentry = d_find_alias(inode); - if (dentry) { - spin_lock(&dentry->d_lock); - name = (const char *) dentry->d_name.name; - } - printk(KERN_DEBUG - "%s(%d): dirtied inode %lu (%s) on %s\n", - current->comm, task_pid_nr(current), inode->i_ino, - name, inode->i_sb->s_id); - if (dentry) { - spin_unlock(&dentry->d_lock); - dput(dentry); - } - } -} - /** * __mark_inode_dirty - internal function to mark an inode dirty * @@ -2296,9 +2274,6 @@ void __mark_inode_dirty(struct inode *inode, int flags) (dirtytime && (inode->i_state & I_DIRTY_INODE))) return; - if (unlikely(block_dump)) - block_dump___mark_inode_dirty(inode); - spin_lock(&inode->i_lock); if (dirtytime && (inode->i_state & I_DIRTY_INODE)) goto out_unlock_inode; -- 2.25.4