linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Guo Xuenan <guoxuenan@huaweicloud.com>
To: Dave Chinner <david@fromorbit.com>
Cc: djwong@kernel.org, dchinner@redhat.com,
	linux-xfs@vger.kernel.org, sandeen@redhat.com,
	guoxuenan@huaweicloud.com, houtao1@huawei.com,
	fangwei1@huawei.com, jack.qiu@huawei.com, yi.zhang@huawei.com
Subject: Re: [PATCH 2/3] xfs: fix xfs print level wrong parsing
Date: Fri, 21 Apr 2023 15:01:28 +0800	[thread overview]
Message-ID: <28628d1f-fa90-9f48-801d-4bcccb88ef48@huaweicloud.com> (raw)
In-Reply-To: <20230421061701.GB3223426@dread.disaster.area>

Hi Dave,

On 2023/4/21 14:17, Dave Chinner wrote:
> On Fri, Apr 21, 2023 at 11:31:41AM +0800, Guo Xuenan wrote:
>> Recently, during my xfs bugfix work, notice a bug that makes
>> xfs_stack_trace never take effect. This has been around here at xfs
>> debug framework for a long time.
>>
>> The root cause is misuse of `kstrtoint` which always return -EINVAL
>> because KERN_<LEVEL> with KERN_SOH prefix unable to parse correctly by
>> it. By skipping the prefix KERN_SOH we can get correct printk level.
>>
>> Fixes: 847f9f6875fb ("xfs: more info from kmem deadlocks and high-level error msgs")
>> Signed-off-by: Guo Xuenan <guoxuenan@huawei.com>
>> ---
>>   fs/xfs/xfs_message.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/fs/xfs/xfs_message.c b/fs/xfs/xfs_message.c
>> index 8f495cc23903..bda4c0a0ca42 100644
>> --- a/fs/xfs/xfs_message.c
>> +++ b/fs/xfs/xfs_message.c
>> @@ -45,7 +45,7 @@ xfs_printk_level(
>>   
>>   	va_end(args);
>>   
>> -	if (!kstrtoint(kern_level, 0, &level) &&
>> +	if (!kstrtoint(kern_level + strlen(KERN_SOH), 0, &level) &&
>>   	    level <= LOGLEVEL_ERR &&
>>   	    xfs_error_level >= XFS_ERRLEVEL_HIGH)
>>   		xfs_stack_trace();
> Ugh. KERN_* is a string with a special character as a header, not
> just an stringified number. Ok, I see how this fixes the bug, but
> let's have a look at where kern_level comes from. i.e.
> xfs_message.h:
>
> extern __printf(3, 4)
> void xfs_printk_level(const char *kern_level, const struct xfs_mount *mp,
>                          const char *fmt, ...);
>
> define xfs_printk_index_wrap(kern_level, mp, fmt, ...)         \
> ({                                                              \
>          printk_index_subsys_emit("%sXFS%s: ", kern_level, fmt); \
>          xfs_printk_level(kern_level, mp, fmt, ##__VA_ARGS__);   \
> })
> #define xfs_emerg(mp, fmt, ...) \
>          xfs_printk_index_wrap(KERN_EMERG, mp, fmt, ##__VA_ARGS__)
> #define xfs_alert(mp, fmt, ...) \
>          xfs_printk_index_wrap(KERN_ALERT, mp, fmt, ##__VA_ARGS__)
> #define xfs_crit(mp, fmt, ...) \
>          xfs_printk_index_wrap(KERN_CRIT, mp, fmt, ##__VA_ARGS__)
> #define xfs_err(mp, fmt, ...) \
>          xfs_printk_index_wrap(KERN_ERR, mp, fmt, ##__VA_ARGS__)
> .....
>
> IOWs, we define the level value directly in these macros, they
> aren't spread throughout the code. Hence we should be able to use
> some preprocessor string concatenation magic here to get rid of the
> kstrtoint() call altogether.
Yes,I adopted a simple but not intuitive way to fix it,
your suggestion is more clear :). v2 will be send after
got your review opinion of the first patch.

Have a good day :)
Xuenan
>   extern __printf(3, 4)
> -void xfs_printk_level(const char *kern_level, const struct xfs_mount *mp,
> -                        const char *fmt, ...);
> +void xfs_printk_level(const char *kern_level, const int log_level,
> +			const struct xfs_mount *mp, const char *fmt, ...);
>
>   define xfs_printk_index_wrap(level, mp, fmt, ...)         \
>   ({                                                              \
> -        printk_index_subsys_emit("%sXFS%s: ", kern_level, fmt); \
> -        xfs_printk_level(kern_level, mp, fmt, ##__VA_ARGS__);   \
> +        printk_index_subsys_emit("%sXFS%s: ", KERN_##level, fmt); \
> +        xfs_printk_level(KERN_##level, LOGLEVEL_##level mp, fmt, ##__VA_ARGS__);   \
>   })
>   #define xfs_emerg(mp, fmt, ...) \
> -        xfs_printk_index_wrap(KERN_EMERG, mp, fmt, ##__VA_ARGS__)
> +        xfs_printk_index_wrap(EMERG, mp, fmt, ##__VA_ARGS__)
>   #define xfs_alert(mp, fmt, ...) \
> -        xfs_printk_index_wrap(KERN_ALERT, mp, fmt, ##__VA_ARGS__)
> -        xfs_printk_index_wrap(ALERT, mp, fmt, ##__VA_ARGS__)
>   #define xfs_crit(mp, fmt, ...) \
> -        xfs_printk_index_wrap(KERN_CRIT, mp, fmt, ##__VA_ARGS__)
> -        xfs_printk_index_wrap(CRIT, mp, fmt, ##__VA_ARGS__)
>   #define xfs_err(mp, fmt, ...) \
> -       xfs_printk_index_wrap(KERN_ERR, mp, fmt, ##__VA_ARGS__)
> -       xfs_printk_index_wrap(ERR, mp, fmt, ##__VA_ARGS__)
> ....
>
> Then xfs_printk_level() is passed the log level as an integer value
> at runtime - the compiler does is all for us - and the code
> is then simply:
>
> 	if (log_level < LOGLEVEL_ERR &&
> 	    xfs_error_level >= XFS_ERRLEVEL_HIGH)
> 		xfs_stack_trace();
>
> Cheers,
>
> Dave.


  reply	other threads:[~2023-04-21  7:02 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-21  3:31 [PATCH 0/3] xfs fixes and clean up Guo Xuenan
2023-04-21  3:31 ` [PATCH 1/3] xfs: fix leak memory when xfs_attr_inactive fails Guo Xuenan
2023-04-21  7:49   ` Dave Chinner
2023-04-21 15:32     ` Darrick J. Wong
2023-04-21 20:54       ` Dave Chinner
2023-05-05  8:16   ` kernel test robot
2023-05-05 11:27     ` Guo Xuenan
2023-04-21  3:31 ` [PATCH 2/3] xfs: fix xfs print level wrong parsing Guo Xuenan
2023-04-21  6:17   ` Dave Chinner
2023-04-21  7:01     ` Guo Xuenan [this message]
2023-04-21  3:31 ` [PATCH 3/3] xfs: clean up some unnecessary xfs_stack_trace Guo Xuenan
2023-04-21  6:18   ` Dave Chinner
2023-04-21  3:50 ` [PATCH 1/3] xfs: fix leak memory when xfs_attr_inactive fails Guo Xuenan

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=28628d1f-fa90-9f48-801d-4bcccb88ef48@huaweicloud.com \
    --to=guoxuenan@huaweicloud.com \
    --cc=david@fromorbit.com \
    --cc=dchinner@redhat.com \
    --cc=djwong@kernel.org \
    --cc=fangwei1@huawei.com \
    --cc=houtao1@huawei.com \
    --cc=jack.qiu@huawei.com \
    --cc=linux-xfs@vger.kernel.org \
    --cc=sandeen@redhat.com \
    --cc=yi.zhang@huawei.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).