Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp118853pxu; Wed, 6 Jan 2021 23:38:23 -0800 (PST) X-Google-Smtp-Source: ABdhPJx4QDpAL6I7vXbJzPAJQyimNdPT6r3GUEbdW6sKwPoPfmtO4PLyAdHEDbYTfmur2J4heAiA X-Received: by 2002:a17:906:7090:: with SMTP id b16mr5601730ejk.76.1610005102906; Wed, 06 Jan 2021 23:38:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610005102; cv=none; d=google.com; s=arc-20160816; b=QXAfbbERDkEW5N2EihqMxLQk+ahoSYd/HkK1XNk/SB3oMIdJ8eLGdAczTvWLIpSGLO nP5d9CW8nxGjYJxbUBp/rduC1wtCBH7e/SZh+qfE8HW2jObZ17ydbAlQl5lTyigdUznF 6gwc6nnZQYGC+kODgk0nloizHBobeuZ3Y1D55yiWv151XbznxVqorDNj6hIjutuDtCt6 GBN4sWPxj//WCy8leKq2oSprErjjhiXiZH15NKqwTcDQN4UYXRzX2+pI70V3o/rUZKs0 3+mR7bYBD1wsw1X/+gsiCcglR0ab250KuSXj2EKcvhZwQi+Uxl8IIZI3KwljDR6JCR0C o8gg== 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=sAFF6LN9qKk2+z87fUmmt/T1HhMprARY+JHTBxUKapE=; b=XMbMFszqT9QfvnQG7eNd//O7HJF93iT2pd3lFUjRRXW6vUf7UqjK5fgmKBHy3DfXEN 5qWfJiKIyzLv/DLHilQriS4yK33FpbLt6C1oI7D/nepbXQT7QkqG5yjIME2RMqS7jFll HoUajuyq/zp2PP373nYbmWa2zC2yM1q/YofMgC9dvxERZ0CtrTgtVY1r8jHUVbWfTWVz 0dwacx2HXGD1V5vqyBtPsPPPRiIQtdgeTHPR8OsjLWMTARP/EeFXkPhrZkyD64rWTTRO chcl6NPP6OCUS2Nr120cGHgXa5Lk7/X41n6uuCO21US8gEamz3B3Y1CorUkIH1H0Z8lC z9ZA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ce20si1997099edb.138.2021.01.06.23.37.59; Wed, 06 Jan 2021 23:38:22 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-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-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726371AbhAGHfp (ORCPT + 99 others); Thu, 7 Jan 2021 02:35:45 -0500 Received: from out30-133.freemail.mail.aliyun.com ([115.124.30.133]:47012 "EHLO out30-133.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726013AbhAGHfp (ORCPT ); Thu, 7 Jan 2021 02:35:45 -0500 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R771e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04420;MF=wenyang@linux.alibaba.com;NM=1;PH=DS;RN=5;SR=0;TI=SMTPD_---0UKyro0-_1610004896; Received: from localhost(mailfrom:wenyang@linux.alibaba.com fp:SMTPD_---0UKyro0-_1610004896) by smtp.aliyun-inc.com(127.0.0.1); Thu, 07 Jan 2021 15:35:02 +0800 From: Wen Yang To: Greg Kroah-Hartman , Sasha Levin Cc: Xunlei Pang , linux-kernel@vger.kernel.org, Wen Yang Subject: [PATCH v2 4.9 00/10] fix a race in release_task when flushing the dentry Date: Thu, 7 Jan 2021 15:34:44 +0800 Message-Id: <20210107073454.62026-1-wenyang@linux.alibaba.com> X-Mailer: git-send-email 2.23.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The dentries such as /proc//ns/ have the DCACHE_OP_DELETE flag, they should be deleted when the process exits. Suppose the following race appears: release_task dput -> proc_flush_task -> dentry->d_op->d_delete(dentry) -> __exit_signal -> dentry->d_lockref.count-- and return. In the proc_flush_task(), if another process is using this dentry, it will not be deleted. At the same time, in dput(), d_op->d_delete() can be executed before __exit_signal(pid has not been hashed), d_delete returns false, so this dentry still cannot be deleted. This dentry will always be cached (although its count is 0 and the DCACHE_OP_DELETE flag is set), its parent denry will also be cached too, and these dentries can only be deleted when drop_caches is manually triggered. This will result in wasted memory. What's more troublesome is that these dentries reference pid, according to the commit f333c700c610 ("pidns: Add a limit on the number of pid namespaces"), if the pid cannot be released, it may result in the inability to create a new pid_ns. This issue was introduced by 60347f6716aa ("pid namespaces: prepare proc_flust_task() to flush entries from multiple proc trees"), exposed by f333c700c610 ("pidns: Add a limit on the number of pid namespaces"), and then fixed by 7bc3e6e55acf ("proc: Use a list of inodes to flush from proc"). Alexey Dobriyan (1): proc: use %u for pid printing and slightly less stack Andreas Gruenbacher (1): proc: Pass file mode to proc_pid_make_inode Christian Brauner (1): clone: add CLONE_PIDFD Eric W. Biederman (6): proc: Better ownership of files for non-dumpable tasks in user namespaces proc: Rename in proc_inode rename sysctl_inodes sibling_inodes proc: Generalize proc_sys_prune_dcache into proc_prune_siblings_dcache proc: Clear the pieces of proc_inode that proc_evict_inode cares about proc: Use d_invalidate in proc_prune_siblings_dcache proc: Use a list of inodes to flush from proc Joel Fernandes (Google) (1): pidfd: add polling support fs/proc/base.c | 242 ++++++++++++++++++++------------------------- fs/proc/fd.c | 20 +--- fs/proc/inode.c | 67 ++++++++++++- fs/proc/internal.h | 22 ++--- fs/proc/namespaces.c | 3 +- fs/proc/proc_sysctl.c | 45 ++------- fs/proc/self.c | 6 +- fs/proc/thread_self.c | 5 +- include/linux/pid.h | 5 + include/linux/proc_fs.h | 4 +- include/uapi/linux/sched.h | 1 + kernel/exit.c | 5 +- kernel/fork.c | 131 +++++++++++++++++++++++- kernel/pid.c | 3 + kernel/signal.c | 11 +++ security/selinux/hooks.c | 1 + 16 files changed, 343 insertions(+), 228 deletions(-) -- 1.8.3.1