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]>