[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJnrk1awtqnSQS0F+TNTuQdLDsAAkArjbu1L=5L1Eoe0fGf31A@mail.gmail.com>
Date: Tue, 2 Sep 2025 10:35:28 -0700
From: Joanne Koong <joannelkoong@...il.com>
To: Luis Henriques <luis@...lia.com>
Cc: Miklos Szeredi <miklos@...redi.hu>, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] fuse: remove WARN_ON_ONCE() from fuse_iomap_writeback_{range,submit}()
On Tue, Sep 2, 2025 at 8:22 AM Luis Henriques <luis@...lia.com> wrote:
>
> The usage of WARN_ON_ONCE doesn't seem to be necessary in these functions.
> All fuse_iomap_writeback_submit() call sites already ensure that wpc->wb_ctx
> contains a valid fuse_fill_wb_data.
Hi Luis,
Maybe I'm misunderstanding the purpose of WARN()s and when they should
be added, but I thought its main purpose is to guarantee that the
assumptions you're relying on are correct, even if that can be
logically deduced in the code. That's how I see it being used in other
parts of the fuse and non-fuse codebase. For instance, to take one
example, in the main fuse dev.c code, there's a WARN_ON in
fuse_request_queue_background() that the request has the FR_BACKGROUND
bit set. All call sites already ensure that the FR_BACKGROUND bit is
set when they send it as a background request. I don't feel strongly
about whether we decide to remove the WARN or not, but it would be
useful to know as a guiding principle when WARNs should be added vs
when they should not.
Thanks,
Joanne
>
> Function fuse_iomap_writeback_range() also seems to always be called with a
> valid value. But even if this wasn't the case, there would be a crash
> before this WARN_ON_ONCE() because ->wpa is being accessed before it.
>
I agree, for the fuse_iomap_writeback_range() case, it would be more
useful if "wpa = data->wpa" was moved below that warn.
> Signed-off-by: Luis Henriques <luis@...lia.com>
> ---
> As I'm saying above, I _think_ there's no need for these WARN_ON_ONCE().
> However, if I'm wrong and they are required, I believe there's a need for
> a different patch (I can send one) to actually prevent a kernel crash.
>
> fs/fuse/file.c | 4 ----
> 1 file changed, 4 deletions(-)
>
> diff --git a/fs/fuse/file.c b/fs/fuse/file.c
> index 5525a4520b0f..fac52f9fb333 100644
> --- a/fs/fuse/file.c
> +++ b/fs/fuse/file.c
> @@ -2142,8 +2142,6 @@ static ssize_t fuse_iomap_writeback_range(struct iomap_writepage_ctx *wpc,
> struct fuse_conn *fc = get_fuse_conn(inode);
> loff_t offset = offset_in_folio(folio, pos);
>
> - WARN_ON_ONCE(!data);
> -
> if (!data->ff) {
> data->ff = fuse_write_file_get(fi);
> if (!data->ff)
> @@ -2182,8 +2180,6 @@ static int fuse_iomap_writeback_submit(struct iomap_writepage_ctx *wpc,
> {
> struct fuse_fill_wb_data *data = wpc->wb_ctx;
>
> - WARN_ON_ONCE(!data);
> -
> if (data->wpa) {
> WARN_ON(!data->wpa->ia.ap.num_folios);
> fuse_writepages_send(wpc->inode, data);
Powered by blists - more mailing lists