From patchwork Mon Apr 14 09:53:36 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christian Brauner X-Patchwork-Id: 14050075 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7741826869D; Mon, 14 Apr 2025 09:54:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744624440; cv=none; b=NfPIYfRgMotQeHG9jQMiW1QTodz37dJbhP0RcvsRW8Qcsx76yNraLYWYKG7g1g5Hz8nvRwDcsq5npOUfkyRQE9okxM1ufp1Q40UoXTqgVkuv6wM+fhnlIJNe3Rz41IiijYt+00IVvwq7+ZyV/xqR91wmYBCWkJTeawZks4IUgn4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744624440; c=relaxed/simple; bh=m9SucPDBiv57vDJTBiHL8Yu+1iS7jJDF3MNROUK+8qQ=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=SgcZ+LIfjYv8pU3urQ0IpolqL43LS9MJOs3KFmOxh/Bbbo3TTmrHS0nEIItWBWsWvy/7pfIAByt+J65eRhFsv9KzBCSNQPVmwYvLCK5SlxOFUNuJHFErE3Udzn9wRaSPmava2hl48AKU6QbOrkt9LJYNy0BVqAY9eGJy00Ybfhk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Fc8ckTZ/; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Fc8ckTZ/" Received: by smtp.kernel.org (Postfix) with ESMTPSA id ED7B5C4CEEB; Mon, 14 Apr 2025 09:53:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1744624439; bh=m9SucPDBiv57vDJTBiHL8Yu+1iS7jJDF3MNROUK+8qQ=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=Fc8ckTZ/SfzFNkOryUV5xlexdLBpVcIYXA2pp9lFG0A7uKvit1zRy0dfLuohd+6ZN /2fl76carqTlfHKuxwxy821zHZMY3p7Zbq1EqSH2W1ar4baYUay8QaEYMzhYak6NqX Lg5S62x/FqfGDbi+vrMhA4gPR6Tzh5/GepYxezks6L9FJl1G0AVK5GHKA1XkvUoGx1 LDziGqR32d/EoEHBS1nJLHdomwVIb1qgqTBWnbKxTA6P6w0H+ScnptbcyMeEUnj34y 6Z2nq9agBaWAX8c+rJ3JVaKbb/dJtFzThHrRFXoCiCS7wDnX26Thkj86UPKkeQGyJ4 PceUbox4hgv4g== From: Christian Brauner Date: Mon, 14 Apr 2025 11:53:36 +0200 Subject: [PATCH 1/3] pidfs: move O_RDWR into pidfs_alloc_file() Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Message-Id: <20250414-work-coredump-v1-1-6caebc807ff4@kernel.org> References: <20250414-work-coredump-v1-0-6caebc807ff4@kernel.org> In-Reply-To: <20250414-work-coredump-v1-0-6caebc807ff4@kernel.org> To: linux-fsdevel@vger.kernel.org Cc: Oleg Nesterov , Luca Boccassi , Lennart Poettering , Daan De Meyer , Mike Yuan , =?utf-8?q?Zbigniew_J=C4=99drzejewski-Szmek?= , linux-kernel@vger.kernel.org, Christian Brauner X-Mailer: b4 0.15-dev-c25d1 X-Developer-Signature: v=1; a=openpgp-sha256; l=1239; i=brauner@kernel.org; h=from:subject:message-id; bh=m9SucPDBiv57vDJTBiHL8Yu+1iS7jJDF3MNROUK+8qQ=; b=owGbwMvMwCU28Zj0gdSKO4sYT6slMaT/uW3ctC82gn9fJDf7KxfjFr2t/6qzDP++9Gh/5hTG+ T/xndjDjlIWBjEuBlkxRRaHdpNwueU8FZuNMjVg5rAygQxh4OIUgIm8tWFkaFqscaZ3b8J0Wc3Z ER5aDzeYZxZE/lr5+MH6068cfyzlkGT4xSS5n3uTY+O2ZuNJ3hEfHLe4V2krlb+OTPjePGfGNsM CHgA= X-Developer-Key: i=brauner@kernel.org; a=openpgp; fpr=4880B8C9BD0E5106FC070F4F7B3C391EFEA93624 Since all pidfds must be O_RDWR currently enfore that directly in the file allocation function itself instead of letting callers specify it. Tested-by: Luca Boccassi Signed-off-by: Christian Brauner --- fs/pidfs.c | 1 + kernel/fork.c | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/pidfs.c b/fs/pidfs.c index d64a4cbeb0da..50e69a9e104a 100644 --- a/fs/pidfs.c +++ b/fs/pidfs.c @@ -888,6 +888,7 @@ struct file *pidfs_alloc_file(struct pid *pid, unsigned int flags) return ERR_PTR(-ESRCH); flags &= ~PIDFD_CLONE; + flags |= O_RDWR; pidfd_file = dentry_open(&path, flags, current_cred()); /* Raise PIDFD_THREAD explicitly as do_dentry_open() strips it. */ if (!IS_ERR(pidfd_file)) diff --git a/kernel/fork.c b/kernel/fork.c index c4b26cd8998b..d184e51196a2 100644 --- a/kernel/fork.c +++ b/kernel/fork.c @@ -2071,7 +2071,7 @@ static int __pidfd_prepare(struct pid *pid, unsigned int flags, struct file **re if (pidfd < 0) return pidfd; - pidfd_file = pidfs_alloc_file(pid, flags | O_RDWR); + pidfd_file = pidfs_alloc_file(pid, flags); if (IS_ERR(pidfd_file)) return PTR_ERR(pidfd_file); From patchwork Mon Apr 14 09:53:37 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christian Brauner X-Patchwork-Id: 14050076 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DBC41269836; Mon, 14 Apr 2025 09:54:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744624443; cv=none; b=SAOqVRGv3KWdj+3iyCsXp2glesX4Cyb/SLbFOM0He1tGhQ/uFnBJjo+igzLOyt+NfQv8CeM63jhTsuLth1YCgJiemVagtqJKV9d6RRKsi/JGvvdxFd30syScfCd3q+QfeOCuOGVJKZ4HP4ByFEYuYBgpTUKVvKlFln1oRCfiJyA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744624443; c=relaxed/simple; bh=Yx0s+29+fWiKG5e4fyOCBvG2yH0V+I1OL3c1XfGljr8=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=J9lyL7SdTaVgTfscAeFsip7YcbTyCHwt8FG3SvQN+6oupWFTTCdqpLqlq6723mhtU8dPWWI+6PtUH3XtIW/8Uz6yLdEB7rmkKOKQpGXgdGi6NJMXaH/Iow73YsyRWT+dJg0rjPhT+TcvSVXBjeoOWSWpRapg72UNum9St8INVJI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=RKTDHglf; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="RKTDHglf" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 638DAC4CEE2; Mon, 14 Apr 2025 09:54:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1744624442; bh=Yx0s+29+fWiKG5e4fyOCBvG2yH0V+I1OL3c1XfGljr8=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=RKTDHglfBRaRk7Z1UhTKUaSYsds+HamSNpTvpeIkZ6BQEo2Xbk5B94ov3jXtVtGBK umErYL1uABCcLXxmZXcw0TcnpYgP5ikIp81TucCnstpanuO906Sw1RY5OoJNmBe4GR bD2I9WFBHU3V6oWwZfo8O9l61BjFiLewP1J9vHdLbTAMCUIO+VRl25gJHRHpkq1XSg kLBVYOUPvWcIyPSv0QOBa7SsWYEfiAIC4L4yW+UYKuuw7oUwrNz/anCALT4tnwIAQL ccnA6WFuQsiVDAfqcDVxLCLgIQ99XwNuWbYnsDFGzMBlE3grqUl4hSYiPTI6JeX8DJ ptzCXHBQTddDA== From: Christian Brauner Date: Mon, 14 Apr 2025 11:53:37 +0200 Subject: [PATCH 2/3] coredump: fix error handling for replace_fd() Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Message-Id: <20250414-work-coredump-v1-2-6caebc807ff4@kernel.org> References: <20250414-work-coredump-v1-0-6caebc807ff4@kernel.org> In-Reply-To: <20250414-work-coredump-v1-0-6caebc807ff4@kernel.org> To: linux-fsdevel@vger.kernel.org Cc: Oleg Nesterov , Luca Boccassi , Lennart Poettering , Daan De Meyer , Mike Yuan , =?utf-8?q?Zbigniew_J=C4=99drzejewski-Szmek?= , linux-kernel@vger.kernel.org, Christian Brauner X-Mailer: b4 0.15-dev-c25d1 X-Developer-Signature: v=1; a=openpgp-sha256; l=1244; i=brauner@kernel.org; h=from:subject:message-id; bh=Yx0s+29+fWiKG5e4fyOCBvG2yH0V+I1OL3c1XfGljr8=; b=owGbwMvMwCU28Zj0gdSKO4sYT6slMaT/uW08eVr2OrPvHOuu/y7Y92Nf7u/HQXrMbN1yNiHan OXTNfUvdpSyMIhxMciKKbI4tJuEyy3nqdhslKkBM4eVCWQIAxenAExEVY3hN9vU3r+h9bts9rPb y/G1rS06ssw/6oOWgVne3sadrUIKpxgZtj4IivTP4zs1mSmo5MZxhfNd4X9KchL+ba0L4ZOvlP/ HBgA= X-Developer-Key: i=brauner@kernel.org; a=openpgp; fpr=4880B8C9BD0E5106FC070F4F7B3C391EFEA93624 The replace_fd() helper returns the file descriptor number on success and a negative error code on failure. The current error handling in umh_pipe_setup() only works because the file descriptor that is replaced is zero but that's pretty volatile. Explicitly check for a negative error code. Tested-by: Luca Boccassi Signed-off-by: Christian Brauner --- fs/coredump.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/fs/coredump.c b/fs/coredump.c index c33c177a701b..2ed5e6956a09 100644 --- a/fs/coredump.c +++ b/fs/coredump.c @@ -507,7 +507,9 @@ static int umh_pipe_setup(struct subprocess_info *info, struct cred *new) { struct file *files[2]; struct coredump_params *cp = (struct coredump_params *)info->data; - int err = create_pipe_files(files, 0); + int err; + + err = create_pipe_files(files, 0); if (err) return err; @@ -515,6 +517,9 @@ static int umh_pipe_setup(struct subprocess_info *info, struct cred *new) err = replace_fd(0, files[0], 0); fput(files[0]); + if (err < 0) + return err; + /* and disallow core files too */ current->signal->rlim[RLIMIT_CORE] = (struct rlimit){1, 1}; From patchwork Mon Apr 14 09:53:38 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christian Brauner X-Patchwork-Id: 14050077 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 660E82698AE; Mon, 14 Apr 2025 09:54:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744624445; cv=none; b=kWA0cIBzGdASomfS+mopHHqyPQmvs0tTVpFhnHLTm7BRjRnVXjGz4izUeSWy79GQAjlWQUsSjNTRBAAonWhcDJy5Bg4avPDLu7dTVFtG+HL4enk1Mu9wRl6IDc74A/+y4KoOXB1xSivcs03ASziNsHwf6JUkQm4SopQyDyVUau0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744624445; c=relaxed/simple; bh=6yyH5aI21gPB/q58TfX/WF+rBvX583JI7wTyHGzGhiA=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=oZ4vx7fVzEWaRToLciiNkeL8uTmofTsl/B1nKKMFfNKVP57RBj5AXk+8xg5zVrqetri/yAyYFtENhEeT1h4d74y+zEyWnq1bGNl7xAl7kcYmA/N6i+naQjzZ9ysiqGxBoLvqXbJ7/D5ftI/LXpFz7wLxSkFfFQ5iInAMnOQnpJM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ELrP3jxf; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ELrP3jxf" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C78BAC4CEEB; Mon, 14 Apr 2025 09:54:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1744624444; bh=6yyH5aI21gPB/q58TfX/WF+rBvX583JI7wTyHGzGhiA=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=ELrP3jxfbXW3baqctu7yTxT7dvuHUm4B+xMgKdYA7AIemQ7DAUC4kxdUqFns6PcEU /nl0/ax0jkpJymMkqhBg+V5M+bDIZmiBalqduSP72jQ+GUh3JYuOje86g2H9cyRUki bKOnZc/ZrxsMp9/R2Ir0F/aB4nhsHlw/HngA5NccxojKw7MoYXvEZZrtjlg7vGPgPZ CeSE5ZEWgflPgb75eEo12rDZJqeL4OTHTcRiOr/s+CSs6fXFYye1Uj6PrGmJ4IAp8r sIXKodBvwO7f2kC5R1RPVm5ePknW7M74JMn2zcdoMUIka2pvsczTjhHzbiy72WuCSY kcpGJhUxXW0Lg== From: Christian Brauner Date: Mon, 14 Apr 2025 11:53:38 +0200 Subject: [PATCH 3/3] coredump: hand a pidfd to the usermode coredump helper Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Message-Id: <20250414-work-coredump-v1-3-6caebc807ff4@kernel.org> References: <20250414-work-coredump-v1-0-6caebc807ff4@kernel.org> In-Reply-To: <20250414-work-coredump-v1-0-6caebc807ff4@kernel.org> To: linux-fsdevel@vger.kernel.org Cc: Oleg Nesterov , Luca Boccassi , Lennart Poettering , Daan De Meyer , Mike Yuan , =?utf-8?q?Zbigniew_J=C4=99drzejewski-Szmek?= , linux-kernel@vger.kernel.org, Christian Brauner X-Mailer: b4 0.15-dev-c25d1 X-Developer-Signature: v=1; a=openpgp-sha256; l=6614; i=brauner@kernel.org; h=from:subject:message-id; bh=6yyH5aI21gPB/q58TfX/WF+rBvX583JI7wTyHGzGhiA=; b=owGbwMvMwCU28Zj0gdSKO4sYT6slMaT/uW3Mt3Ku1446Kzv30uOeDkXlDVxXE468nbA5pm32+ l+hZVfOdJSyMIhxMciKKbI4tJuEyy3nqdhslKkBM4eVCWQIAxenAEzkRhXD/xjGApnwjhqpg9qH /gtO7+KXNbn4K1/EvunLbs8PkhJeOgz/c7+tu77uK0O/VubiYOWFeqd8nOt9H0o4PFsUvF6/uWI TMwA= X-Developer-Key: i=brauner@kernel.org; a=openpgp; fpr=4880B8C9BD0E5106FC070F4F7B3C391EFEA93624 Give userspace a way to instruct the kernel to install a pidfd into the usermode helper process. This makes coredump handling a lot more reliable for userspace. In parallel with this commit we already have systemd adding support for this in [1]. We create a pidfs file for the coredumping process when we process the corename pattern. When the usermode helper process is forked we then install the pidfs file as file descriptor three into the usermode helpers file descriptor table so it's available to the exec'd program. Since usermode helpers are either children of the system_unbound_wq workqueue or kthreadd we know that the file descriptor table is empty and can thus always use three as the file descriptor number. Note, that we'll install a pidfd for the thread-group leader even if a subthread is calling do_coredump(). We know that task linkage hasn't been removed due to delay_group_leader() and even if this @current isn't the actual thread-group leader we know that the thread-group leader cannot be reaped until @current has exited. Link: https://github.com/systemd/systemd/pull/37125 [1] Tested-by: Luca Boccassi Signed-off-by: Christian Brauner --- fs/coredump.c | 85 +++++++++++++++++++++++++++++++++++++++++++++--- include/linux/coredump.h | 1 + 2 files changed, 82 insertions(+), 4 deletions(-) diff --git a/fs/coredump.c b/fs/coredump.c index 2ed5e6956a09..ae0c1c5efe9a 100644 --- a/fs/coredump.c +++ b/fs/coredump.c @@ -43,6 +43,9 @@ #include #include #include +#include +#include +#include #include #include @@ -60,6 +63,12 @@ static void free_vma_snapshot(struct coredump_params *cprm); #define CORE_FILE_NOTE_SIZE_DEFAULT (4*1024*1024) /* Define a reasonable max cap */ #define CORE_FILE_NOTE_SIZE_MAX (16*1024*1024) +/* + * File descriptor number for the pidfd for the thread-group leader of + * the coredumping task installed into the usermode helper's file + * descriptor table. + */ +#define COREDUMP_PIDFD_NUMBER 3 static int core_uses_pid; static unsigned int core_pipe_limit; @@ -339,6 +348,58 @@ static int format_corename(struct core_name *cn, struct coredump_params *cprm, case 'C': err = cn_printf(cn, "%d", cprm->cpu); break; + /* pidfd number */ + case 'F': { + struct file *pidfs_file __free(fput) = NULL; + + /* + * Install a pidfd only makes sense if + * we actually spawn a usermode helper. + */ + if (!ispipe) + break; + + /* + * We already created a pidfs_file but the user + * specified F multiple times. Just print the + * number multiple times. + */ + if (!cprm->pidfs_file) { + /* + * Create a pidfs file for the + * coredumping thread that we can + * install into the usermode helper's + * file descriptor table later. + * + * Note that we'll install a pidfd for + * the thread-group leader. We know that + * task linkage hasn't been removed yet + * and even if this @current isn't the + * actual thread-group leader we know + * that the thread-group leader cannot + * be reaped until @current has exited. + */ + pidfs_file = pidfs_alloc_file(task_tgid(current), 0); + if (IS_ERR(pidfs_file)) + return PTR_ERR(pidfs_file); + } + + /* + * Usermode helpers are childen of + * either system_unbound_wq or of + * kthreadd. So we know that we're + * starting off with a clean file + * descriptor table. Thus, we should + * always be able to use file descriptor + * number 3. + */ + err = cn_printf(cn, "%d", COREDUMP_PIDFD_NUMBER); + if (err) + return err; + + cprm->pidfs_file = no_free_ptr(pidfs_file); + break; + } default: break; } @@ -493,7 +554,7 @@ static void wait_for_dump_helpers(struct file *file) } /* - * umh_pipe_setup + * umh_coredump_setup * helper function to customize the process used * to collect the core in userspace. Specifically * it sets up a pipe and installs it as fd 0 (stdin) @@ -503,12 +564,26 @@ static void wait_for_dump_helpers(struct file *file) * is a special value that we use to trap recursive * core dumps */ -static int umh_pipe_setup(struct subprocess_info *info, struct cred *new) +static int umh_coredump_setup(struct subprocess_info *info, struct cred *new) { struct file *files[2]; struct coredump_params *cp = (struct coredump_params *)info->data; + struct file *pidfs_file = cp->pidfs_file; int err; + if (pidfs_file) { + /* We must start from a pristine file descriptor table. */ + VFS_WARN_ON_ONCE((pidfs_file = fget_raw(COREDUMP_PIDFD_NUMBER)) != NULL); + + /* + * Takes it's own reference on success and do_coredump() + * will put the additional reference. + */ + err = replace_fd(COREDUMP_PIDFD_NUMBER, pidfs_file, 0); + if (err < 0) + return err; + } + err = create_pipe_files(files, 0); if (err) return err; @@ -598,7 +673,7 @@ void do_coredump(const kernel_siginfo_t *siginfo) } if (cprm.limit == 1) { - /* See umh_pipe_setup() which sets RLIMIT_CORE = 1. + /* See umh_coredump_setup() which sets RLIMIT_CORE = 1. * * Normally core limits are irrelevant to pipes, since * we're not writing to the file system, but we use @@ -637,7 +712,7 @@ void do_coredump(const kernel_siginfo_t *siginfo) retval = -ENOMEM; sub_info = call_usermodehelper_setup(helper_argv[0], helper_argv, NULL, GFP_KERNEL, - umh_pipe_setup, NULL, &cprm); + umh_coredump_setup, NULL, &cprm); if (sub_info) retval = call_usermodehelper_exec(sub_info, UMH_WAIT_EXEC); @@ -784,6 +859,8 @@ void do_coredump(const kernel_siginfo_t *siginfo) if (ispipe) atomic_dec(&core_dump_count); fail_unlock: + if (cprm.pidfs_file) + fput(cprm.pidfs_file); kfree(argv); kfree(cn.corename); coredump_finish(core_dumped); diff --git a/include/linux/coredump.h b/include/linux/coredump.h index 77e6e195d1d6..af2ed4b68dcf 100644 --- a/include/linux/coredump.h +++ b/include/linux/coredump.h @@ -28,6 +28,7 @@ struct coredump_params { int vma_count; size_t vma_data_size; struct core_vma_metadata *vma_meta; + struct file *pidfs_file; }; extern unsigned int core_file_note_size_limit;