Re: [PATCH v2] btrfs: use %pe for error code output
Jeff Layton <[email protected]> Wed, 22 Jul 2026 08:10:31 -0400
| Newsgroups | org.kernel.vger.linux-btrfs |
|---|---|
| Message-ID | <[email protected]> |
On Wed, 2026-07-22 at 17:04 +0930, Qu Wenruo wrote: > During an interrupted mount, I got the following messages: > > workqueue: Failed to create a rescuer kthread for wq "btrfs-qgroup-rescan": -EINTR > BTRFS error (device dm-3): open_ctree failed: -12 > > Workqueue code is outputting a human readable error string, meanwhile > we're still using a numeric error code. > > So follow the workqueue code to use "%pe" format, which will > automatically convert an error pointer to the human readable string. > > However this is a minor pitfall, if the return value is not an error > code, e.g. a positive number, "%pe" with "ERR_PTR(ret)" will output the > pointer as a hash value, e.g.: > > ret=1 %pe out=0000000019414716 > ret=-22 %pe out=-EINVAL > > So we should not use this "%pe" output for callsites that are known to > return positive values. > > Signed-off-by: Qu Wenruo <[email protected]> > --- > Changelog: > v2: > - Revert the change in iterate_leaf_refs() > Pointed out by sashiko where we can get positive return value. > > - Slightly update the commit message > To mention that we should not use "%pe" for return values that can > be positive. > --- > fs/btrfs/delayed-inode.c | 12 +++---- > fs/btrfs/disk-io.c | 76 +++++++++++++++++++++------------------- > fs/btrfs/extent-tree.c | 20 +++++------ > fs/btrfs/extent_io.c | 8 ++--- > fs/btrfs/inode.c | 31 ++++++++-------- > fs/btrfs/ioctl.c | 4 +-- > fs/btrfs/messages.c | 10 +++--- > fs/btrfs/qgroup.c | 8 ++--- > fs/btrfs/root-tree.c | 6 ++-- > fs/btrfs/super.c | 2 +- > fs/btrfs/transaction.c | 8 ++--- > fs/btrfs/verity.c | 2 +- > 12 files changed, 94 insertions(+), 93 deletions(-) > It would be nice if there were a specifier that did this without requiring you to do an ERR_PTR() cast. Oh well. Reviewed-by: Jeff Layton <[email protected]>