From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Eric Sandeen <sandeen@redhat.com>
Cc: linux-xfs <linux-xfs@vger.kernel.org>
Subject: Re: [PATCH] xfs: define printk_once variants for xfs messages
Date: Mon, 27 Apr 2020 10:21:22 -0700 [thread overview]
Message-ID: <20200427172122.GR6742@magnolia> (raw)
In-Reply-To: <c3aee5bb-806a-d51d-0c0f-b0d6a10fa737@redhat.com>
On Wed, Apr 22, 2020 at 09:36:34PM -0500, Eric Sandeen wrote:
> There are a couple places where we directly call printk_once() and one
> of them doesn't follow the standard xfs subsystem printk format as a
> result.
>
> #define printk_once variants to go with our existing printk_ratelimited
> #defines so we can do one-shot printks in a consistent manner.
>
> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Looks ok,
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
--D
> ---
>
> diff --git a/fs/xfs/xfs_message.h b/fs/xfs/xfs_message.h
> index 0b05e10995a0..802a96190d22 100644
> --- a/fs/xfs/xfs_message.h
> +++ b/fs/xfs/xfs_message.h
> @@ -31,15 +31,27 @@ void xfs_debug(const struct xfs_mount *mp, const char *fmt, ...)
> }
> #endif
>
> -#define xfs_printk_ratelimited(func, dev, fmt, ...) \
> +#define xfs_printk_ratelimited(func, dev, fmt, ...) \
> do { \
> static DEFINE_RATELIMIT_STATE(_rs, \
> DEFAULT_RATELIMIT_INTERVAL, \
> DEFAULT_RATELIMIT_BURST); \
> if (__ratelimit(&_rs)) \
> - func(dev, fmt, ##__VA_ARGS__); \
> + func(dev, fmt, ##__VA_ARGS__); \
> } while (0)
>
> +#define xfs_printk_once(func, dev, fmt, ...) \
> +({ \
> + static bool __section(.data.once) __print_once; \
> + bool __ret_print_once = !__print_once; \
> + \
> + if (!__print_once) { \
> + __print_once = true; \
> + func(dev, fmt, ##__VA_ARGS__); \
> + } \
> + unlikely(__ret_print_once); \
> +})
> +
> #define xfs_emerg_ratelimited(dev, fmt, ...) \
> xfs_printk_ratelimited(xfs_emerg, dev, fmt, ##__VA_ARGS__)
> #define xfs_alert_ratelimited(dev, fmt, ...) \
> @@ -57,6 +69,11 @@ do { \
> #define xfs_debug_ratelimited(dev, fmt, ...) \
> xfs_printk_ratelimited(xfs_debug, dev, fmt, ##__VA_ARGS__)
>
> +#define xfs_warn_once(dev, fmt, ...) \
> + xfs_printk_once(xfs_warn, dev, fmt, ##__VA_ARGS__)
> +#define xfs_notice_once(dev, fmt, ...) \
> + xfs_printk_once(xfs_notice, dev, fmt, ##__VA_ARGS__)
> +
> void assfail(struct xfs_mount *mp, char *expr, char *f, int l);
> void asswarn(struct xfs_mount *mp, char *expr, char *f, int l);
>
> diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c
> index c5513e5a226a..bb91f04266b9 100644
> --- a/fs/xfs/xfs_mount.c
> +++ b/fs/xfs/xfs_mount.c
> @@ -1300,10 +1300,9 @@ xfs_mod_fdblocks(
> spin_unlock(&mp->m_sb_lock);
> return 0;
> }
> - printk_once(KERN_WARNING
> - "Filesystem \"%s\": reserve blocks depleted! "
> - "Consider increasing reserve pool size.",
> - mp->m_super->s_id);
> + xfs_warn_once(mp,
> +"Reserve blocks depleted! Consider increasing reserve pool size.");
> +
> fdblocks_enospc:
> spin_unlock(&mp->m_sb_lock);
> return -ENOSPC;
> diff --git a/fs/xfs/xfs_pnfs.c b/fs/xfs/xfs_pnfs.c
> index bb3008d390aa..b101feb2aab4 100644
> --- a/fs/xfs/xfs_pnfs.c
> +++ b/fs/xfs/xfs_pnfs.c
> @@ -58,9 +58,8 @@ xfs_fs_get_uuid(
> {
> struct xfs_mount *mp = XFS_M(sb);
>
> - printk_once(KERN_NOTICE
> -"XFS (%s): using experimental pNFS feature, use at your own risk!\n",
> - mp->m_super->s_id);
> + xfs_notice_once(mp,
> +"Using experimental pNFS feature, use at your own risk!");
>
> if (*len < sizeof(uuid_t))
> return -EINVAL;
>
prev parent reply other threads:[~2020-04-27 17:21 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-23 2:36 [PATCH] xfs: define printk_once variants for xfs messages Eric Sandeen
2020-04-24 11:44 ` Brian Foster
2020-04-27 17:21 ` Darrick J. Wong [this message]
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=20200427172122.GR6742@magnolia \
--to=darrick.wong@oracle.com \
--cc=linux-xfs@vger.kernel.org \
--cc=sandeen@redhat.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).