From: "Darrick J. Wong" <djwong@kernel.org>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: cem@kernel.org, hch@lst.de, linux-xfs@vger.kernel.org
Subject: Re: [PATCH 1/3] xfs: add xfs_error_report the ability to display an error code
Date: Tue, 8 Sep 2026 10:02:05 -0700 [thread overview]
Message-ID: <20260908170205.GG2619314@frogsfrogsfrogs> (raw)
In-Reply-To: <8a9d507c-f060-4f78-9035-5393b633df11@sandeen.net>
On Tue, Sep 08, 2026 at 11:53:57AM -0500, Eric Sandeen wrote:
> On 9/8/26 9:54 AM, cem@kernel.org wrote:
> > From: Carlos Maiolino <cem@kernel.org>
> >
> > Users could opt to request an error code to be printed now.
> > This relies on errname() and CONFIG_SYMBOLIC_NAME without requiring it
> > to be enabled.
> > Report 'unkown error' If CONFIG_SYMBOLIC_NAME is not enabled or the
> > user passes 0 as an error.
>
> s/SYMBOLIC_NAME/SYMBOLIC_ERRNAME/g
>
> > Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
> > ---
> > fs/xfs/xfs_error.c | 13 ++++++++++---
> > fs/xfs/xfs_error.h | 10 +++++-----
> > fs/xfs/xfs_exchmaps_item.c | 9 ++++++---
> > fs/xfs/xfs_inode_item.c | 3 ++-
> > fs/xfs/xfs_log_recover.c | 3 ++-
> > fs/xfs/xfs_trans.c | 2 +-
> > 6 files changed, 26 insertions(+), 14 deletions(-)
> >
> > diff --git a/fs/xfs/xfs_error.c b/fs/xfs/xfs_error.c
> > index dbd87e137694..3177ec58bb2e 100644
> > --- a/fs/xfs/xfs_error.c
> > +++ b/fs/xfs/xfs_error.c
> > @@ -14,6 +14,7 @@
> > #include "xfs_error.h"
> > #include "xfs_sysfs.h"
> > #include "xfs_inode.h"
> > +#include <linux/errname.h>
> >
> > #ifdef DEBUG
> >
> > @@ -377,15 +378,21 @@ void
> > xfs_error_report(
> > const char *tag,
> > int level,
> > + int error,
> > struct xfs_mount *mp,
> > const char *filename,
> > int linenum,
> > xfs_failaddr_t failaddr)
> > {
> > + const char *err_str = errname(error);
> > +
> > + if (!err_str)
> > + err_str = "unknown error";
> > +
> > if (level <= xfs_error_level) {
> > xfs_alert_tag(mp, XFS_PTAG_ERROR_REPORT,
> > - "Internal error %s at line %d of file %s. Caller %pS",
> > - tag, linenum, filename, failaddr);
> > + "Internal error %s (%s) at line %d of file %s. Caller %pS",
> > + tag, err_str, linenum, filename, failaddr);
> I might suggest making the printk conditional, rather than making err_str conditional.
>
> It might make the code messier, but the entire purpose of this change is to give
> the user more information and a clearer view of what happened. Changing
> "error 93 at line" to "error 93 (unknown error) at line" doesn't really do that,
> and IMHO adds confusion and adds no value.
Oh, something like:
if (level <= xfs_error_level) {
const char *err_str = errname(error);
if (err_str)
xfs_alert_tag(mp, XFS_PTAG_ERROR_REPORT,
"Internal error %s (%s) at line...", tag, err_str, ...);
else
xfs_alert_tag(mp, XFS_PTAG_ERROR_REPORT,
"Internal error %s (%d) at line...", tag, error, ...);
}
Hm?
I sorta like having the #define'd error name in the log message (e.g.
"Internal error frogs (ENOENT) at line..." but tbh these days I just run
errno(1) to translate an errno to a sentence fragment.
--D
> It sounds like the config is typically enabled, but I'd still rather not add
> extra words to debugging printks that add no useful info if possible. It may
> raise more questions than it answers.
>
> overall I like the idea though :)
>
> -Eric
>
next prev parent reply other threads:[~2026-09-08 17:02 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-08 14:54 [PATCH 0/3] Enable xfs error reporting to print out error codes cem
2026-09-08 14:54 ` [PATCH 1/3] xfs: add xfs_error_report the ability to display an error code cem
2026-09-08 15:16 ` Darrick J. Wong
2026-09-10 9:24 ` Carlos Maiolino
2026-09-08 16:53 ` Eric Sandeen
2026-09-08 17:02 ` Darrick J. Wong [this message]
2026-09-08 20:40 ` Eric Sandeen
2026-09-10 9:33 ` Carlos Maiolino
2026-09-08 14:54 ` [PATCH 2/3] xfs: enable xfs_trans_cancel() to report and " cem
2026-09-08 15:27 ` Darrick J. Wong
2026-09-10 9:17 ` Carlos Maiolino
2026-09-08 14:54 ` [PATCH 3/3] xfs: make xfs_iomap_write_direct() report an error to xfs_trans_cancel cem
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=20260908170205.GG2619314@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=cem@kernel.org \
--cc=hch@lst.de \
--cc=linux-xfs@vger.kernel.org \
--cc=sandeen@sandeen.net \
/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.