From: Damien Le Moal <dlemoal@kernel.org>
To: Niklas Cassel <cassel@kernel.org>, Jens Axboe <axboe@kernel.dk>,
Vincent Fu <vincent.fu@samsung.com>
Cc: fio@vger.kernel.org, Jorgen S Hansen <jorgen.hansen@wdc.com>
Subject: Re: [PATCH 2/3] io_u: Fix inconsistent handling of non-fatal errors with option error_dump
Date: Fri, 13 Feb 2026 12:17:20 +0900 [thread overview]
Message-ID: <d22e6af8-667b-4000-94a8-3fab53c75607@kernel.org> (raw)
In-Reply-To: <20260206164058.3105327-3-cassel@kernel.org>
On 2/7/26 01:40, Niklas Cassel wrote:
> Commit 8b28bd413759 ("backend: Add configurable non fatal error list")
> added an early return in io_u_log_error() for non-fatal errors.
>
> This early return is performed if the error is a non-fatal error, and if
> error_dump is not set.
>
> Looking at the help text for the error_dump option:
> "If set dump every error even if it is non fatal, true by default.
> If disabled only fatal error will be dumped."
>
> So this commit made sure that, if error dump is NOT set:
> For a non-fatal error, io_u_log_error() will return early and will thus:
> 1) NOT print an error to the log
> 2) NOT call td_verror()
>
> However, if error dump is set, io_u_log_error() will not do an early
> return, instead it will log the non-fatal error and then call td_verror().
>
> It is clear that the intention is for a non-fatal error to not set
> td->error. (If error_dump is used it should _log_ the non-fatal error.)
>
> Thus, fix the code such that if error_dump is set, for a non-fatal error,
> we:
> 1) print an error to the log
> 2) NOT call td_verror()
>
> This will make the behavior in io_u_log_error() consistent.
> If error_dump is set, we will log the non-fatal error, but regardless of
> error_dump being set or not, we do NOT call td_verror() (which would set
> td->error) for a non-fatal error, since that was obviously the intention
> of commit 8b28bd413759 ("backend: Add configurable non fatal error list").
>
> Fixes: 8b28bd413759 ("backend: Add configurable non fatal error list")
> Signed-off-by: Niklas Cassel <cassel@kernel.org>
Looks OK to me.
Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
--
Damien Le Moal
Western Digital Research
next prev parent reply other threads:[~2026-02-13 3:17 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-06 16:40 [PATCH 0/3] fio: Avoid errno and errno string mismatch Niklas Cassel
2026-02-06 16:40 ` [PATCH 1/3] fio: Fix error string not matching errno Niklas Cassel
2026-02-13 3:12 ` Damien Le Moal
2026-02-06 16:40 ` [PATCH 2/3] io_u: Fix inconsistent handling of non-fatal errors with option error_dump Niklas Cassel
2026-02-13 3:17 ` Damien Le Moal [this message]
2026-02-06 16:40 ` [PATCH 3/3] stat: Remove duplicate space in __show_run_stats() Niklas Cassel
2026-02-13 3:17 ` Damien Le Moal
2026-02-06 17:57 ` [PATCH 0/3] fio: Avoid errno and errno string mismatch fiotestbot
2026-02-14 2:39 ` Vincent Fu
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=d22e6af8-667b-4000-94a8-3fab53c75607@kernel.org \
--to=dlemoal@kernel.org \
--cc=axboe@kernel.dk \
--cc=cassel@kernel.org \
--cc=fio@vger.kernel.org \
--cc=jorgen.hansen@wdc.com \
--cc=vincent.fu@samsung.com \
/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