From: Eric Sandeen <sandeen@redhat.com>
To: linux-fsdevel@vger.kernel.org
Cc: Christian Brauner <brauner@kernel.org>,
David Howells <dhowells@redhat.com>,
Alexander Viro <aviro@redhat.com>,
Bill O'Donnell <billodo@redhat.com>, Karel Zak <kzak@redhat.com>
Subject: [PATCH RFC] vfs: always log mount API fs context messages to dmesg
Date: Thu, 22 Feb 2024 09:22:52 -0600 [thread overview]
Message-ID: <9934ed50-5760-4326-a921-cee0239355b0@redhat.com> (raw)
As filesystems are converted to the new mount API, informational messages,
errors, and warnings are being routed through infof, errorf, and warnf
type functions provided by the mount API, which places these messages in
the log buffer associated with the filesystem context rather than
in the kernel log / dmesg.
However, userspace is not yet extracting these messages, so they are
essentially getting lost. mount(8) still refers the user to dmesg(1)
on failure.
At least for now, modify logfc() to always log these messages to dmesg
as well as to the fileystem context. This way we can continue converting
filesystems to the new mount API interfaces without worrying about losing
this information until userspace can retrieve it.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
---
A few considerations/concerns:
* viro suggested that maybe this should be conditional - possibly config
* systemd is currently probing with a dummy mount option which will
generate noise, see
https://github.com/systemd/systemd/blob/main/src/basic/mountpoint-util.c#L759
i.e. -
[ 10.689256] proc: Unknown parameter 'adefinitelynotexistingmountoption'
[ 10.801045] tmpfs: Unknown parameter 'adefinitelynotexistingmountoption'
[ 11.119431] proc: Unknown parameter 'adefinitelynotexistingmountoption'
[ 11.692032] proc: Unknown parameter 'adefinitelynotexistingmountoption'
* will this generate other dmesg noise in general if the mount api messages
are more noisy in general? (spot-checking old conversions, I don't think so.)
fs/fs_context.c | 38 ++++++++++++++++++++------------------
1 file changed, 20 insertions(+), 18 deletions(-)
diff --git a/fs/fs_context.c b/fs/fs_context.c
index 98589aae5208..3c78b99d5cae 100644
--- a/fs/fs_context.c
+++ b/fs/fs_context.c
@@ -427,8 +427,8 @@ struct fs_context *vfs_dup_fs_context(struct fs_context *src_fc)
EXPORT_SYMBOL(vfs_dup_fs_context);
/**
- * logfc - Log a message to a filesystem context
- * @log: The filesystem context to log to, or NULL to use printk.
+ * logfc - Log a message to dmesg and optionally a filesystem context
+ * @log: The filesystem context to log to, or NULL to use printk alone
* @prefix: A string to prefix the output with, or NULL.
* @level: 'w' for a warning, 'e' for an error. Anything else is a notice.
* @fmt: The format of the buffer.
@@ -439,22 +439,24 @@ void logfc(struct fc_log *log, const char *prefix, char level, const char *fmt,
struct va_format vaf = {.fmt = fmt, .va = &va};
va_start(va, fmt);
- if (!log) {
- switch (level) {
- case 'w':
- printk(KERN_WARNING "%s%s%pV\n", prefix ? prefix : "",
- prefix ? ": " : "", &vaf);
- break;
- case 'e':
- printk(KERN_ERR "%s%s%pV\n", prefix ? prefix : "",
- prefix ? ": " : "", &vaf);
- break;
- default:
- printk(KERN_NOTICE "%s%s%pV\n", prefix ? prefix : "",
- prefix ? ": " : "", &vaf);
- break;
- }
- } else {
+ switch (level) {
+ case 'w':
+ printk(KERN_WARNING "%s%s%pV\n", prefix ? prefix : "",
+ prefix ? ": " : "", &vaf);
+ break;
+ case 'e':
+ printk(KERN_ERR "%s%s%pV\n", prefix ? prefix : "",
+ prefix ? ": " : "", &vaf);
+ break;
+ default:
+ printk(KERN_NOTICE "%s%s%pV\n", prefix ? prefix : "",
+ prefix ? ": " : "", &vaf);
+ break;
+ }
+ va_end(va);
+
+ va_start(va, fmt);
+ if (log) {
unsigned int logsize = ARRAY_SIZE(log->buffer);
u8 index;
char *q = kasprintf(GFP_KERNEL, "%c %s%s%pV\n", level,
--
2.43.0
next reply other threads:[~2024-02-22 15:23 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-22 15:22 Eric Sandeen [this message]
2024-02-22 15:58 ` [PATCH RFC] vfs: always log mount API fs context messages to dmesg Bill O'Donnell
2024-02-22 16:08 ` Darrick J. Wong
2024-02-23 15:56 ` Christian Brauner
2024-02-24 1:58 ` Darrick J. Wong
2024-02-26 10:51 ` Christian Brauner
2024-02-23 15:06 ` Christian Brauner
2024-02-23 16:27 ` Eric Sandeen
2024-02-26 11:21 ` Christian Brauner
2024-02-26 9:04 ` Karel Zak
2024-02-27 1:27 ` Kent Overstreet
2024-02-26 11:27 ` Christian Brauner
2024-02-26 15:23 ` Eric Sandeen
2024-02-27 1:21 ` Ian Kent
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=9934ed50-5760-4326-a921-cee0239355b0@redhat.com \
--to=sandeen@redhat.com \
--cc=aviro@redhat.com \
--cc=billodo@redhat.com \
--cc=brauner@kernel.org \
--cc=dhowells@redhat.com \
--cc=kzak@redhat.com \
--cc=linux-fsdevel@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;
as well as URLs for NNTP newsgroup(s).