From: Christian Brauner <brauner@kernel.org>
To: Laura Brehm <laurajfbrehm@gmail.com>
Cc: linux-kernel@vger.kernel.org, Laura Brehm <laurabrehm@hey.com>,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 2/2] coredump: fix PIDFD_INFO_COREDUMP ioctl check
Date: Fri, 4 Jul 2025 10:57:27 +0200 [thread overview]
Message-ID: <20250704-badeanstalt-eurem-b944cdc46c4c@brauner> (raw)
In-Reply-To: <20250703120244.96908-3-laurabrehm@hey.com>
On Thu, Jul 03, 2025 at 02:02:44PM +0200, Laura Brehm wrote:
> In Commit 1d8db6fd698de1f73b1a7d72aea578fdd18d9a87 ("pidfs,
> coredump: add PIDFD_INFO_COREDUMP"), the following code was added:
>
> if (mask & PIDFD_INFO_COREDUMP) {
> kinfo.mask |= PIDFD_INFO_COREDUMP;
> kinfo.coredump_mask = READ_ONCE(pidfs_i(inode)->__pei.coredump_mask);
> }
> [...]
> if (!(kinfo.mask & PIDFD_INFO_COREDUMP)) {
> task_lock(task);
> if (task->mm)
> kinfo.coredump_mask = pidfs_coredump_mask(task->mm->flags);
> task_unlock(task);
> }
>
> The second bit in particular looks off to me - the condition in essence
> checks whether PIDFD_INFO_COREDUMP was **not** requested, and if so
> fetches the coredump_mask in kinfo, since it's checking !(kinfo.mask &
> PIDFD_INFO_COREDUMP), which is unconditionally set in the earlier hunk.
>
> I'm tempted to assume the idea in the second hunk was to calculate the
> coredump mask if one was requested but fetched in the first hunk, in
> which case the check should be
> if ((kinfo.mask & PIDFD_INFO_COREDUMP) && !(kinfo.coredump_mask))
> which might be more legibly written as
> if ((mask & PIDFD_INFO_COREDUMP) && !(kinfo.coredump_mask))
>
> This could also instead be achieved by changing the first hunk to be:
>
> if (mask & PIDFD_INFO_COREDUMP) {
> kinfo.coredump_mask = READ_ONCE(pidfs_i(inode)->__pei.coredump_mask);
> if (kinfo.coredump_mask)
> kinfo.mask |= PIDFD_INFO_COREDUMP;
> }
>
> and the second hunk to:
>
> if ((mask & PIDFD_INFO_COREDUMP) && !(kinfo.mask & PIDFD_INFO_COREDUMP)) {
> task_lock(task);
> if (task->mm) {
> kinfo.coredump_mask = pidfs_coredump_mask(task->mm->flags);
> kinfo.mask |= PIDFD_INFO_COREDUMP;
> }
> task_unlock(task);
> }
>
> However, when looking at this, the supposition that the second hunk
> means to cover cases where the coredump info was requested but the first
> hunk failed to get it starts getting doubtful, so apologies if I'm
> completely off-base.
>
> This patch addresses the issue by fixing the check in the second hunk.
>
> Signed-off-by: Laura Brehm <laurabrehm@hey.com>
> Cc: brauner@kernel.org
> Cc: linux-fsdevel@vger.kernel.org
> ---
Yes, that looks correct to me. Thanks for the fix!
prev parent reply other threads:[~2025-07-04 8:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20250703120244.96908-1-laurabrehm@hey.com>
2025-07-03 12:02 ` [PATCH 1/2] coredump: fix race condition between connect and putting pidfs dentry Laura Brehm
2025-07-04 8:51 ` Christian Brauner
2025-07-04 10:40 ` [PATCH 1/2] coredump: fix race condition between connect and Laura Brehm
2025-07-03 12:02 ` [PATCH 2/2] coredump: fix PIDFD_INFO_COREDUMP ioctl check Laura Brehm
2025-07-04 8:57 ` (subset) " Christian Brauner
2025-07-04 8:57 ` Christian Brauner [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250704-badeanstalt-eurem-b944cdc46c4c@brauner \
--to=brauner@kernel.org \
--cc=laurabrehm@hey.com \
--cc=laurajfbrehm@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox