From: Anand Jain <anand.jain@oracle.com>
To: linux-btrfs@vger.kernel.org
Cc: dsterba@suse.cz
Subject: [PATCH 1/4] btrfs: add NO_FS_INFO to btrfs_printk
Date: Tue, 14 Jan 2020 14:09:17 +0800 [thread overview]
Message-ID: <20200114060920.4527-1-anand.jain@oracle.com> (raw)
The first argument to btrfs_printk() wrappers such as
btrfs_warn_in_rcu(), btrfs_info_in_rcu(), etc.. is fs_info, but in some
context like scan and assembling of the volumes there isn't fs_info yet,
so those code generally don't use the btrfs_printk() wrappers and it
could could still use NULL but then it would become hard to distinguish
whether fs_info is NULL for genuine reason or a bug.
So introduce a define NO_FS_INFO to be used instead of NULL so that we
know the code where fs_info isn't initialized and also we have a
consistent logging functions. Thanks.
Suggested-by: David Sterba <dsterba@suse.com>
Signed-off-by: Anand Jain <anand.jain@oracle.com>
---
fs/btrfs/ctree.h | 5 +++++
fs/btrfs/super.c | 14 +++++++++++---
2 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index 569931dd0ce5..625c7eee3d0f 100644
--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/ctree.h
@@ -110,6 +110,11 @@ struct btrfs_ref;
#define BTRFS_STAT_CURR 0
#define BTRFS_STAT_PREV 1
+/*
+ * Used when we know that fs_info is not yet initialized.
+ */
+#define NO_FS_INFO ((void *)0x1)
+
/*
* Count how many BTRFS_MAX_EXTENT_SIZE cover the @size
*/
diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index a906315efd19..5bd8a889fed0 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -216,9 +216,17 @@ 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 == NULL)
+ printk("%sBTRFS %s (device %s): %pV\n", lvl, type,
+ "<unknown>", &vaf);
+ else if (fs_info == NO_FS_INFO)
+ printk("%sBTRFS %s (device %s): %pV\n", lvl, type,
+ "...", &vaf);
+ else
+ printk("%sBTRFS %s (device %s): %pV\n", lvl, type,
+ fs_info->sb->s_id, &vaf);
+ }
va_end(args);
}
--
2.23.0
next reply other threads:[~2020-01-14 6:09 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-14 6:09 Anand Jain [this message]
2020-01-14 6:09 ` [PATCH 2/4] btrfs: stop using uninitiazlised fs_info in device_list_add() Anand Jain
2020-01-14 6:58 ` Qu Wenruo
2020-01-14 7:30 ` Nikolay Borisov
2020-01-14 6:09 ` [PATCH 3/4] btrfs: make the scan logs consistent Anand Jain
2020-01-14 6:09 ` [PATCH 4/4] btrfs: use btrfs consistent logging wrappers Anand Jain
2020-01-14 6:54 ` [PATCH 1/4] btrfs: add NO_FS_INFO to btrfs_printk Qu Wenruo
2020-01-14 7:21 ` Anand Jain
2020-01-14 7:31 ` Nikolay Borisov
2020-01-14 7:33 ` Qu Wenruo
2020-01-22 15:50 ` David Sterba
2020-01-23 7:22 ` Anand Jain
2020-02-03 4:06 ` Anand Jain
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=20200114060920.4527-1-anand.jain@oracle.com \
--to=anand.jain@oracle.com \
--cc=dsterba@suse.cz \
--cc=linux-btrfs@vger.kernel.org \
/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.