All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Down <chris@chrisdown.name>
To: Petr Mladek <pmladek@suse.com>
Cc: Jonathan Lassoff <jof@thejof.com>,
	linux-xfs@vger.kernel.org, "Darrick J. Wong" <djwong@kernel.org>,
	Dave Chinner <david@fromorbit.com>,
	Sergey Senozhatsky <senozhatsky@chromium.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	John Ogness <john.ogness@linutronix.de>
Subject: Re: [PATCH v3 2/2] Add XFS messages to printk index
Date: Wed, 30 Mar 2022 13:05:24 +0100	[thread overview]
Message-ID: <YkRHhJT2dLu4ypwR@chrisdown.name> (raw)
In-Reply-To: <YkMKyN9w0S8VFJRk@alley>

Hi Petr,

Petr Mladek writes:
>On Fri 2022-03-25 10:19:46, Jonathan Lassoff wrote:
>> In order for end users to quickly react to new issues that come up in
>> production, it is proving useful to leverage the printk indexing system.
>> This printk index enables kernel developers to use calls to printk()
>> with changeable ad-hoc format strings, while still enabling end users
>> to detect changes from release to release.
>>
>> So that detailed XFS messages are captures by this printk index, this
>> patch wraps the xfs_<level> and xfs_alert_tag functions.
>>
>> Signed-off-by: Jonathan Lassoff <jof@thejof.com>
>
>> --- a/fs/xfs/xfs_message.h
>> +++ b/fs/xfs/xfs_message.h
>> @@ -6,34 +6,45 @@
>>
>>  struct xfs_mount;
>>
>> +#define xfs_printk_index_wrap(kern_level, mp, fmt, ...)		\
>> +({								\
>> +	printk_index_subsys_emit("%sXFS%s: ", kern_level, fmt);	\
>
>I would probably use "%sXFS: " for the first parameter as
>a compromise here.
>
>It affects how the printk formats are shown in debugfs. With the
>current patch I see in /sys/kernel/debug/printk/index/vmlinux:
>
><4> fs/xfs/libxfs/xfs_ag.c:877 xfs_ag_shrink_space "%sXFS%s: Error %d reserving per-AG metadata reserve pool."
><1> fs/xfs/libxfs/xfs_ag.c:151 xfs_initialize_perag_data "%sXFS%s: AGF corruption. Please run xfs_repair."
><4> fs/xfs/libxfs/xfs_alloc.c:2429 xfs_agfl_reset "%sXFS%s: WARNING: Reset corrupted AGFL on AG %u. %d blocks leaked. Please unmount and run xfs_repair."
><4> fs/xfs/libxfs/xfs_alloc.c:262 xfs_alloc_get_rec "%sXFS%s: start block 0x%x block count 0x%x"
><4> fs/xfs/libxfs/xfs_alloc.c:260 xfs_alloc_get_rec "%sXFS%s: %s Freespace BTree record corruption in AG %d detected!"
><1> fs/xfs/libxfs/xfs_attr_remote.c:304 xfs_attr_rmtval_copyout "%sXFS%s: remote attribute header mismatch bno/off/len/owner (0x%llx/0x%x/Ox%x/0x%llx)"
><4> fs/xfs/libxfs/xfs_bmap.c:1129 xfs_iread_bmbt_block "%sXFS%s: corrupt dinode %llu, (btree extents)."
>
>In reality, the prefix is chosen in __xfs_printk() at runtime:
>
>	+ "%sXFS (%s): "	when mp->m_super is defined
>	+ "%sXFS: "		otherwise
>
>It means that "%sXFS: " is not perfect but it looks closer to reality
>than "%sXFS%s: ".

I think we do actually want "%sXFS%s: " here. Without that, it's not possible to 
be confident marrying up a userspace detector to its original printk 
counterpart if the detector actually looks at what's in mp->m_super->s_id (eg.  
to exclude or include some device).

Some messages in practice also typically only ever come out with mp->m_super 
present, so the userspace detector is likely to accomodate for that whether it 
uses the data in mp->m_super->s_id or not. Since we can't detect which printks 
those are at compile time, we pretty much have to use "%sXFS%s: ".

Thanks,

Chris

  parent reply	other threads:[~2022-03-30 12:10 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-25 17:19 [PATCH v3 1/2] Simplify XFS logging methods Jonathan Lassoff
2022-03-25 17:19 ` [PATCH v3 2/2] Add XFS messages to printk index Jonathan Lassoff
2022-03-29 13:34   ` Petr Mladek
2022-03-30  0:34     ` Dave Chinner
2022-03-30  0:46       ` Darrick J. Wong
2022-03-30  1:26         ` Dave Chinner
2022-03-30 14:59           ` Petr Mladek
2022-03-30 15:07             ` Chris Down
2022-03-31 15:06               ` Darrick J. Wong
2022-04-05 12:55                 ` Petr Mladek
2022-03-31  9:14             ` Sergey Senozhatsky
2022-03-30 11:52       ` Chris Down
2022-03-30 16:47         ` Steven Rostedt
2022-03-30 17:09           ` Chris Down
2022-03-30 17:25             ` Chris Down
2022-03-30 17:39             ` Steven Rostedt
2022-03-30 17:44               ` Chris Down
2022-03-30 21:02           ` Dave Chinner
2022-03-31 14:09             ` Petr Mladek
2022-04-01 21:50               ` Dave Chinner
2022-03-30 12:05     ` Chris Down [this message]
2022-03-30  0:05   ` Dave Chinner
2022-03-30 12:07   ` Chris Down
2022-03-31  1:38     ` Jonathan Lassoff
2022-03-29 13:03 ` [PATCH v3 1/2] Simplify XFS logging methods Petr Mladek
2022-03-29 23:54 ` Dave Chinner
2022-03-30 11:40   ` Petr Mladek
2022-03-30 11:55 ` Chris Down

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=YkRHhJT2dLu4ypwR@chrisdown.name \
    --to=chris@chrisdown.name \
    --cc=david@fromorbit.com \
    --cc=djwong@kernel.org \
    --cc=jof@thejof.com \
    --cc=john.ogness@linutronix.de \
    --cc=linux-xfs@vger.kernel.org \
    --cc=pmladek@suse.com \
    --cc=rostedt@goodmis.org \
    --cc=senozhatsky@chromium.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.