Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp126252pxu; Wed, 6 Jan 2021 23:56:12 -0800 (PST) X-Google-Smtp-Source: ABdhPJxtj4BS+waEQXjm+HRDeuzaruMElzxRaUt7vznmJdWLKemLaZenBba9K2z/fy/3mY85PH7q X-Received: by 2002:a05:6402:40e:: with SMTP id q14mr748880edv.85.1610006172561; Wed, 06 Jan 2021 23:56:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610006172; cv=none; d=google.com; s=arc-20160816; b=ydwKmoaowNds8/TlSHeDc+Ts7YgZpkiWfScOx+1qhGpBcFSAleRTHG9bvFsO9qooZF lJO5P9Ykt/31KCLbdGPTmX4O50RzEkW/XTmXHpfzkU7moFKrc5XorEAlFemrQdptNw/G u3G+3RGIstNqIJlY/AQWe9YGv0q9XUtEZa1bFpeXc6WPOgwFDqa1X6dbncF4KzZ4EAjH TXNVDP+ERGJn6x9FnQEMRZBtnye7ukRUZUTenSixozsob5mtHkHe9iP7prKXfK/eZSRC 10cE/AuUg2h1ay2loDDdFWfInfNBkonEmvCeaQGZwy9A6j3lEZOkQaGLWEGkzyLgem/q QDMA== 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=IMRVcuYD5PIiKjYIfKErf23PGyadF7Z0w+TQO9QGB4s=; b=SDuoeTQH+vQKlMskMDzvIfvwSMmWgJ8rkBikJX8Uy0SHdnUuw7tEf1M/Tnrv1s7kAv hbnUr/nNHb1c7wGZkSB6KfLd3/zqJgd2cH8tU/0SrK6lgidkRBT3pZ9yySsqY1eX1X/2 kXBssHTb6WzX/r0Thao/4pnKShdQclvq+vDCS5s342uimrdNKYRHFETC7RK4lH2eCIfj x8ohlTr41EZ834akMDauHkV7oW1Guwi9SVG0vUXIfoeGE4+rBv/tWL4JkrdBBWc+Vh+H OIZLCk4pzxDeuTYebTT1PgU52cUQ6YkDVZ5X7nRduxn7jc0JEalIUGNZegvpDKjIBZG1 8nWA== 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 n3si1864228ejx.102.2021.01.06.23.55.48; Wed, 06 Jan 2021 23:56:12 -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 S1727395AbhAGHx7 (ORCPT + 99 others); Thu, 7 Jan 2021 02:53:59 -0500 Received: from out30-57.freemail.mail.aliyun.com ([115.124.30.57]:38212 "EHLO out30-57.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726505AbhAGHx6 (ORCPT ); Thu, 7 Jan 2021 02:53:58 -0500 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R161e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04400;MF=wenyang@linux.alibaba.com;NM=1;PH=DS;RN=5;SR=0;TI=SMTPD_---0UKz-a3D_1610005995; Received: from localhost(mailfrom:wenyang@linux.alibaba.com fp:SMTPD_---0UKz-a3D_1610005995) by smtp.aliyun-inc.com(127.0.0.1); Thu, 07 Jan 2021 15:53:15 +0800 From: Wen Yang To: Greg Kroah-Hartman , Sasha Levin Cc: Xunlei Pang , linux-kernel@vger.kernel.org, Wen Yang Subject: [PATCH 4.19 0/7] fix a race in release_task when flushing the dentry Date: Thu, 7 Jan 2021 15:53:07 +0800 Message-Id: <20210107075314.62683-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"). Christian Brauner (1): clone: add CLONE_PIDFD Eric W. Biederman (5): 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 | 111 ++++++++++++------------------------- fs/proc/inode.c | 67 +++++++++++++++++++++-- fs/proc/internal.h | 4 +- fs/proc/proc_sysctl.c | 45 ++------------- include/linux/pid.h | 6 ++ include/linux/proc_fs.h | 4 +- include/uapi/linux/sched.h | 1 + kernel/exit.c | 4 +- kernel/fork.c | 133 +++++++++++++++++++++++++++++++++++++++++++-- kernel/pid.c | 3 + kernel/signal.c | 11 ++++ 11 files changed, 262 insertions(+), 127 deletions(-) -- 1.8.3.1