From: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
To: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
Cc: Chris Mason <clm@fb.com>, Josef Bacik <josef@toxicpanda.com>,
David Sterba <dsterba@suse.com>,
linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] btrfs: add fs state details to error messages.
Date: Tue, 15 Feb 2022 11:07:01 -0500 [thread overview]
Message-ID: <dc7bfe199bf22e67061a358e8e1f32b2@dorminy.me> (raw)
In-Reply-To: <20220215150438.GN12643@twin.jikos.cz>
>> +static void btrfs_state_to_string(const struct btrfs_fs_info *info,
>> char *buf)
>> +{
>> + unsigned long state = info->fs_state;
>> + char *curr = buf;
>> +
>> + memcpy(curr, STATE_STRING_PREFACE, sizeof(STATE_STRING_PREFACE));
>> + curr += sizeof(STATE_STRING_PREFACE) - 1;
>> +
>> + /* If more states are reported, update MAX_STATE_CHARS also */
>> + if (test_and_clear_bit(BTRFS_FS_STATE_ERROR, &state))
>
> The state is supposed to be sticky, so can't be cleared. Also as I read
> the suggested change, the "state: " should be visible for all messages
> that are printed after the filesystem state changes.
'state' is a local copy of info->fs_state, so clearing bits on the local
copy should be okay, and the "state: " will be present for everything
after the fs state changes. Could instead use test_bit(&info->fs_state)
and keep a count of how many states were printed (to know if we need to
reset the buffer) if that is clearer.
>
>> + *curr++ = 'E';
>> +
>> + if (test_and_clear_bit(BTRFS_FS_STATE_TRANS_ABORTED, &state))
>> + *curr++ = 'X';
>> +
>> + /* If no states were printed, reset the buffer */
>> + if (state == info->fs_state)
>> + curr = buf;
>> +
>> + *curr++ = '\0';
>> +}
>> +
>> /*
>> * Generally the error codes correspond to their respective errors,
>> but there
>> * are a few special cases.
>> @@ -128,6 +153,7 @@ void __btrfs_handle_fs_error(struct btrfs_fs_info
>> *fs_info, const char *function
>> {
>> struct super_block *sb = fs_info->sb;
>> #ifdef CONFIG_PRINTK
>> + char statestr[sizeof(STATE_STRING_PREFACE) + MAX_STATE_CHARS];
>> const char *errstr;
>> #endif
>>
>> @@ -136,10 +162,11 @@ void __btrfs_handle_fs_error(struct
>> btrfs_fs_info *fs_info, const char *function
>> * under SB_RDONLY, then it is safe here.
>> */
>> if (errno == -EROFS && sb_rdonly(sb))
>> - return;
>> + return;
>
> Unnecessary change.
Yeah, there's a stray space at the start of that line, but I can take
out fixing it.
>
>>
>> #ifdef CONFIG_PRINTK
>> errstr = btrfs_decode_error(errno);
>> + btrfs_state_to_string(fs_info, statestr);
>> if (fmt) {
>> struct va_format vaf;
>> va_list args;
>> @@ -148,12 +175,12 @@ void __btrfs_handle_fs_error(struct
>> btrfs_fs_info *fs_info, const char *function
>> vaf.fmt = fmt;
>> vaf.va = &args;
>>
>> - pr_crit("BTRFS: error (device %s) in %s:%d: errno=%d %s (%pV)\n",
>> - sb->s_id, function, line, errno, errstr, &vaf);
>> + pr_crit("BTRFS: error (device %s%s) in %s:%d: errno=%d %s (%pV)\n",
>> + sb->s_id, statestr, function, line, errno, errstr, &vaf);
>
> Alternatively the state message can be built into the message itself so
> it does not require the extra array.
>
>
> pr_crit("btrfs: error(device %s%s%s%s) ...",
> sb->s_id,
> statebits ? ", state" : "",
> test_bit(FS_ERRROR) ? "E" : "",
> test_bit(TRANS_ABORT) ? "T" : "", ...);
>
> This is the idea, final code can use some wrappers around the bit
> constatnts.
>
>
>> va_end(args);
>> } else {
>> - pr_crit("BTRFS: error (device %s) in %s:%d: errno=%d %s\n",
>> - sb->s_id, function, line, errno, errstr);
>> + pr_crit("BTRFS: error (device %s%s) in %s:%d: errno=%d %s\n",
>> + sb->s_id, statestr, function, line, errno, errstr);
>
> Filling the temporary array makes sense as it's used twice, however I'm
> not sure if the 'else' branch is ever executed.
There are a bunch of calls with NULL format -> else branch,
unfortunately.
Thanks!
prev parent reply other threads:[~2022-02-15 16:07 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-12 19:10 [PATCH] btrfs: add fs state details to error messages Sweet Tea Dorminy
2022-02-15 15:04 ` David Sterba
2022-02-15 16:07 ` Sweet Tea Dorminy [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=dc7bfe199bf22e67061a358e8e1f32b2@dorminy.me \
--to=sweettea-kernel@dorminy.me \
--cc=clm@fb.com \
--cc=dsterba@suse.com \
--cc=josef@toxicpanda.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox