Received: by 2002:a05:6602:18e:0:0:0:0 with SMTP id m14csp5225834ioo; Wed, 1 Jun 2022 00:37:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx1Ck/WNP8j74EHdB5H0MysjmSS/QHpYouvC2aAIVSEoXx6ScADLIM0tWz5BUGcv9qQ8WVR X-Received: by 2002:a17:903:40ce:b0:164:248:1464 with SMTP id t14-20020a17090340ce00b0016402481464mr7729229pld.16.1654069034841; Wed, 01 Jun 2022 00:37:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654069034; cv=none; d=google.com; s=arc-20160816; b=M/MgH6pXAv3ceWKzgyUlLrG07rMjThqiYfiFeAB7qVGByvujr7Z4v0LiFlrOtqv0hs T4BptZq+4xf7kptYXKifwKgMmuiDzku/noXQ8RMQLLPXBtgBATfMfulvpydfuPBPK8tW 83/+XVfK3dTNOWQm5/DkI7CjpiEYQbiRt/Lo46VbRxbDOh8C78siDBN+NImpr3LpQWbH XXAeqt8Uitm3O0p9hEkOhMoWWjSS+96/lA25uWsp7J/E6wkzcsJ9t+NlAtBCuWPyp6CW ALFp51cTLRa4CJRdk72Ooa4abPA/UpKAAeJ1M5DDnzlGAZuGEQsos9yfcdm2t+n1UgbZ eMSQ== 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=l+MM3GcL2DChxk2oy8sVnoCGXULnsFXj7KH9LftCKOQ=; b=hEEeugUvDH74sUjeBLwKT9rrcdtRMx2+LoAIA3ChWbB5khQxW4RVTlKnNZk2CIdQYr qXP4ABP8/rZ8w7wJ0Lhm9b06rx0+lz0OILuX49YMY/ZKc8EPlWyOvtGXeYDks4PDfNWT tow/d8IE7SD89x5Zk36i9BLZa9WK1UurQ8+GxQUUysjpcundQhvVHXQnArGDJkosvUOX Rcdcf7FHxuSqilVKZhA/KqkFYzIXRgDFGvM3zgSajEcB6eFCue4R1cM2LRDjPSjZilmc b9ZsNTPKZL+qQr93h7E3d2s0uapc28euQ+Svi7UaFYyMO0qFX4Ot3Law5xxvJk9uwdVn QiLg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id k7-20020a170902c40700b0016206ea00cbsi1926409plk.61.2022.06.01.00.37.00; Wed, 01 Jun 2022 00:37:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349092AbiFACE1 (ORCPT + 99 others); Tue, 31 May 2022 22:04:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54342 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345940AbiFACEZ (ORCPT ); Tue, 31 May 2022 22:04:25 -0400 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 63D9E72E18; Tue, 31 May 2022 19:04:22 -0700 (PDT) Received: from kwepemi100012.china.huawei.com (unknown [172.30.72.53]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4LCXTs42RczgYMX; Wed, 1 Jun 2022 10:02:41 +0800 (CST) Received: from kwepemm600013.china.huawei.com (7.193.23.68) by kwepemi100012.china.huawei.com (7.221.188.202) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Wed, 1 Jun 2022 10:04:21 +0800 Received: from huawei.com (10.175.127.227) by kwepemm600013.china.huawei.com (7.193.23.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Wed, 1 Jun 2022 10:04:20 +0800 From: Zhihao Cheng To: CC: , , , , Subject: [PATCH v2] proc: Fix a dentry lock race between release_task and lookup Date: Wed, 1 Jun 2022 10:17:42 +0800 Message-ID: <20220601021742.4163063-1-chengzhihao1@huawei.com> X-Mailer: git-send-email 2.31.1 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.175.127.227] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To kwepemm600013.china.huawei.com (7.193.23.68) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Commit 7bc3e6e55acf06 ("proc: Use a list of inodes to flush from proc") moved proc_flush_task() behind __exit_signal(). Then, process systemd can take long period high cpu usage during releasing task in following concurrent processes: systemd ps kernel_waitid stat(/proc/tgid) do_wait filename_lookup wait_consider_task lookup_fast release_task __exit_signal __unhash_process detach_pid __change_pid // remove task->pid_links d_revalidate -> pid_revalidate // 0 d_invalidate(/proc/tgid) shrink_dcache_parent(/proc/tgid) d_walk(/proc/tgid) spin_lock_nested(/proc/tgid/fd) // iterating opened fd proc_flush_pid | d_invalidate (/proc/tgid/fd) | shrink_dcache_parent(/proc/tgid/fd) | shrink_dentry_list(subdirs) ↓ shrink_lock_dentry(/proc/tgid/fd) --> race on dentry lock Function d_invalidate() will remove dentry from hash firstly, but why does proc_flush_pid() process dentry '/proc/tgid/fd' before dentry '/proc/tgid'? That's because proc_pid_make_inode() adds proc inode in reverse order by invoking hlist_add_head_rcu(). But proc should not add any inodes under '/proc/tgid' except '/proc/tgid/task/pid', fix it by adding inode into 'pid->inodes' only if the inode is /proc/tgid or /proc/tgid/task/pid. Fixes: 7bc3e6e55acf06 ("proc: Use a list of inodes to flush from proc") Link: https://bugzilla.kernel.org/show_bug.cgi?id=216054 Signed-off-by: Zhihao Cheng Signed-off-by: Zhang Yi --- v1->v2: Add new helper proc_pid_make_base_inode that performs the extra work of adding to the pid->list fs/proc/base.c | 34 ++++++++++++++++++++++++++-------- 1 file changed, 26 insertions(+), 8 deletions(-) diff --git a/fs/proc/base.c b/fs/proc/base.c index c1031843cc6a..f22fad3bf7f0 100644 --- a/fs/proc/base.c +++ b/fs/proc/base.c @@ -1885,7 +1885,7 @@ void proc_pid_evict_inode(struct proc_inode *ei) put_pid(pid); } -struct inode *proc_pid_make_inode(struct super_block * sb, +struct inode *proc_pid_make_inode(struct super_block *sb, struct task_struct *task, umode_t mode) { struct inode * inode; @@ -1914,11 +1914,6 @@ struct inode *proc_pid_make_inode(struct super_block * sb, /* Let the pid remember us for quick removal */ ei->pid = pid; - if (S_ISDIR(mode)) { - spin_lock(&pid->lock); - hlist_add_head_rcu(&ei->sibling_inodes, &pid->inodes); - spin_unlock(&pid->lock); - } task_dump_owner(task, 0, &inode->i_uid, &inode->i_gid); security_task_to_inode(task, inode); @@ -1931,6 +1926,27 @@ struct inode *proc_pid_make_inode(struct super_block * sb, return NULL; } +struct inode *proc_pid_make_base_inode(struct super_block *sb, + struct task_struct *task, umode_t mode) +{ + struct inode *inode; + struct proc_inode *ei; + struct pid *pid; + + inode = proc_pid_make_inode(sb, task, mode); + if (!inode) + return NULL; + + /* Let proc_flush_pid find this directory inode */ + ei = PROC_I(inode); + pid = ei->pid; + spin_lock(&pid->lock); + hlist_add_head_rcu(&ei->sibling_inodes, &pid->inodes); + spin_unlock(&pid->lock); + + return inode; +} + int pid_getattr(struct user_namespace *mnt_userns, const struct path *path, struct kstat *stat, u32 request_mask, unsigned int query_flags) { @@ -3350,7 +3366,8 @@ static struct dentry *proc_pid_instantiate(struct dentry * dentry, { struct inode *inode; - inode = proc_pid_make_inode(dentry->d_sb, task, S_IFDIR | S_IRUGO | S_IXUGO); + inode = proc_pid_make_base_inode(dentry->d_sb, task, + S_IFDIR | S_IRUGO | S_IXUGO); if (!inode) return ERR_PTR(-ENOENT); @@ -3649,7 +3666,8 @@ static struct dentry *proc_task_instantiate(struct dentry *dentry, struct task_struct *task, const void *ptr) { struct inode *inode; - inode = proc_pid_make_inode(dentry->d_sb, task, S_IFDIR | S_IRUGO | S_IXUGO); + inode = proc_pid_make_base_inode(dentry->d_sb, task, + S_IFDIR | S_IRUGO | S_IXUGO); if (!inode) return ERR_PTR(-ENOENT); -- 2.31.1