From: Luis Henriques <luis@igalia.com>
To: Joanne Koong <joannelkoong@gmail.com>
Cc: "Darrick J. Wong" <djwong@kernel.org>,
Miklos Szeredi <miklos@szeredi.hu>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel-dev@igalia.com
Subject: Re: [PATCH v2] fuse: prevent possible NULL pointer dereference in fuse_iomap_writeback_{range,submit}()
Date: Thu, 04 Sep 2025 09:24:06 +0100 [thread overview]
Message-ID: <878qiumxqx.fsf@wotan.olymp> (raw)
In-Reply-To: <CAJnrk1aa97AwixCq9+eGQT52LAfqL-S1Ci5fSUygfFOo-6kMHA@mail.gmail.com> (Joanne Koong's message of "Wed, 3 Sep 2025 15:32:40 -0700")
On Wed, Sep 03 2025, Joanne Koong wrote:
> On Wed, Sep 3, 2025 at 1:48 PM Darrick J. Wong <djwong@kernel.org> wrote:
>> ...because if someone fails to set wpc->wb_ctx, this line will crash the
>> kernel at least as much as the WARN_ON would. IOWs, the WARN_ONs aren't
>> necessary but I don't think they hurt much.
>>
>
> Oh, I see. Actually, this explanation makes a lot of sense. When I was
> looking at the other WARN_ON usages in fuse, I noticed they were also
> used even if it's logically proven that the code path can never be
> triggered. But I guess what you're saying is that WARN_ONs in general
> should be used if it's otherwise somehow undetectable / non-obvious
> that the condition is violated? That makes sense to me, and checks out
> with the other fuse WARN_ON uses.
>
> I'm fine with just removing the WARN_ON(!data) here and below. I think
> I added some more WARN_ONs in my other fuse iomap patchset, so I'll
> remove those as well when I send out a new version.
I don't have a preference between v1 and v2 of this patch. v1 removed the
WARNs because I don't think they are useful:
1. the assertions are never true, but
2. if they are, they are useless because we'll hit a NULL pointer
dereference anyway.
v2 tries to fix the code assuming the assertions can be triggered.
So, yeah I'll just leave the 3 options (v1, v2, or do nothing) on the
table :-)
Cheers,
--
Luís
next prev parent reply other threads:[~2025-09-04 8:48 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-03 8:34 [PATCH v2] fuse: prevent possible NULL pointer dereference in fuse_iomap_writeback_{range,submit}() Luis Henriques
2025-09-03 17:03 ` Joanne Koong
2025-09-03 20:08 ` Luis Henriques
2025-09-03 20:48 ` Darrick J. Wong
2025-09-03 22:32 ` Joanne Koong
2025-09-04 2:46 ` Darrick J. Wong
2025-09-04 8:24 ` Luis Henriques [this message]
2025-09-04 8:40 ` Miklos Szeredi
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=878qiumxqx.fsf@wotan.olymp \
--to=luis@igalia.com \
--cc=djwong@kernel.org \
--cc=joannelkoong@gmail.com \
--cc=kernel-dev@igalia.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.