From: David Howells <dhowells@redhat.com>
To: ksummit-discuss@lists.linuxfoundation.org
Subject: [Ksummit-discuss] [TECH TOPIC] Getting better/supplementary error info back to userspace
Date: Wed, 12 Jul 2017 13:43:30 +0100 [thread overview]
Message-ID: <10144.1499863410@warthog.procyon.org.uk> (raw)
Whilst undertaking a foray into container space and, related to that, looking
at overhauling the mounting API, it occurred to me that I could make use of
the mount context (now fs_context) that I was creating to allow the filesystem
driver to pass supplementary error information back to the userspace program
that was driving it in the form of textual messages:
int fd = fsopen("ext4");
write(fd, "d /dev/sda2");
write(fd, "o user_xattr");
if (fsmount(fd, "/mnt") == -1) {
/* Something went wrong, read back any error info */
size = read(fd, buffer, sizeof(buffer));
/* Now print the supplementary error message */
fprintf(stderr, "%*.*s\n", size, size, buffer);
}
This would be particularly useful in the case of mounting a filesystem where
so many things can go wrong that a small number is insufficient to represent
them all. Yes, you have the dmesg log, but that's not necessarily available
to you and is potentially intermixed with other things. Further, it's more
user-friendly if the mount command or your GUI gives you the errors directly.
However, it occurred to me that this feature might be useful in other cases,
not just mounting, and there are cases where it's not easy or not possible to
get the message back to userspace because there's no user-accessible context
(eg. automounting), or because the context is buried several levels down the
stack (eg. NFS mount doing a pathwalk).
In which case, would it make sense to attach such a facility to the
task_struct instead? I implemented a test of this using prctl, but a new
syscall might be a better idea, at least for reading.
(*) int old_setting = prctl(PR_ERRMSG_ENABLE, int setting);
Enable (setting == 1) or disable (setting == 0) the facility.
Disabling the facility clears the error buffer.
(*) int size = prctl(PR_ERRMSG_READ, char *buffer, int buf_size);
Read back a message and discard it.
Anyway, some questions:
(1) Is this something that would be of interest on a more global scale?
Or should I just stick with stashing it in the fs_context structure and
find someway to route around the pathwalk in nfs mount?
Or is this totally a bad idea and only dmesg should ever be used?
If it is of interest globally:
(2) How big should I make each task's message buffer? My current
implementation allows each task to hold a single message if enabled.
(3) Should I allow warnings in addition to errors?
(4) Should I allow wait() and co. to try and retrieve errors from zombies?
(5) Should execve() disable the facility?
(6) Could all the messages be static (not kmalloc'd) and cleared/redacted by
rmmod? This would potentially prevent the use of formatted messages.
David
next reply other threads:[~2017-07-12 12:43 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-12 12:43 David Howells [this message]
2017-07-12 14:33 ` [Ksummit-discuss] [TECH TOPIC] Getting better/supplementary error info back to userspace Arnaldo Carvalho de Melo
2017-07-12 14:44 ` Arnaldo Carvalho de Melo
2017-07-12 14:57 ` David Howells
2017-07-12 15:21 ` Stephen Hemminger
2017-07-12 16:19 ` Linus Torvalds
2017-07-12 16:35 ` Stephen Hemminger
2017-07-19 13:02 ` Steven Rostedt
2017-07-24 7:55 ` Miklos Szeredi
2017-07-24 8:25 ` David Howells
2017-07-21 13:41 ` David Howells
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=10144.1499863410@warthog.procyon.org.uk \
--to=dhowells@redhat.com \
--cc=ksummit-discuss@lists.linuxfoundation.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 read-only IMAP folder(s) and NNTP newsgroup(s).