[PATCH] btrfs: remove stub device info from messages when we have no fs_info

[PATCH] btrfs: remove stub device info from messages when we have no fs_info

[David Sterba]

Without a NULL fs_info the helpers will print something like

	BTRFS error (device <unknown>): ...

This can happen in contexts where fs_info is not available at all or
it's potentially unsafe due to object lifetime. The <unknown> stub does
not bring much information and with the prefix makes the message
unnecessarily longer.

Remove it for the NULL fs_info case.

	BTRFS error: ...

Callers can add the device information to the message itself if needed.

Signed-off-by: David Sterba <dsterba@suse.com>
---
 fs/btrfs/super.c | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index 6693cfc14dfd..348f8899f4f4 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -240,9 +240,13 @@ void __cold btrfs_printk(const struct btrfs_fs_info *fs_info, const char *fmt, .
 	vaf.fmt = fmt;
 	vaf.va = &args;
 
-	if (__ratelimit(ratelimit))
-		printk("%sBTRFS %s (device %s): %pV\n", lvl, type,
-			fs_info ? fs_info->sb->s_id : "<unknown>", &vaf);
+	if (__ratelimit(ratelimit)) {
+		if (fs_info)
+			printk("%sBTRFS %s (device %s): %pV\n", lvl, type,
+				fs_info->sb->s_id, &vaf);
+		else
+			printk("%sBTRFS %s: %pV\n", lvl, type, &vaf);
+	}
 
 	va_end(args);
 }
-- 
2.25.0

Re: [PATCH] btrfs: remove stub device info from messages when we have no fs_info

[Anand Jain]

On 20/11/20 11:43 pm, David Sterba wrote:
> Without a NULL fs_info the helpers will print something like
> 
> 	BTRFS error (device <unknown>): ...
> 
> This can happen in contexts where fs_info is not available at all or
> it's potentially unsafe due to object lifetime. The <unknown> stub does
> not bring much information and with the prefix makes the message
> unnecessarily longer.
> 
> Remove it for the NULL fs_info case.
> 
> 	BTRFS error: ...
> 
> Callers can add the device information to the message itself if needed.
> 
> Signed-off-by: David Sterba <dsterba@suse.com>

Reviewed-by: Anand Jain <anand.jain@oracle.com>