Messages in this thread | | | Subject | Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting | From | Johannes Berg <> | Date | Tue, 25 Aug 2015 11:34:06 +0200 |
| |
On Tue, 2015-08-25 at 11:17 +0200, Ingo Molnar wrote: > > If we do that then we don't even have to introduce per system call error code > conversion, but could unconditionally save the last extended error info in the > task struct and continue - this could be done very cheaply with the linker trick > driven integer ID. > > I.e. system calls could opt in to do: > > > return err_str(-EBUSY, "perf/x86: BTS conflicts with active events"); > > and the overhead of this would be minimal, we'd essentially do something like this > to save the error: > > > current->err_code = code; > > where 'code' is a build time constant in essence. > > We could use this even in system calls where the error path is performance > critical, as all the string recovery and copying overhead would be triggered by > applications that opt in via the new system call: > > > struct err_desc { > > const char *message; > > const char *owner; > > const int code; > > }; > > > SyS_err_get_desc(struct err_desc *err_desc __user); > > [ Which could perhaps be a prctl() extension as well (PR_GET_ERR_DESC): finally > some truly matching functionality for prctl(). ] > > Hm?
That's neat in a way, but doesn't work in general I think.
Considering the wifi case, or more generally any netlink based protocol, the syscall (sendmsg) won't return an error, but a subsequent recvmsg() (which also won't return an error) returns an error message [in the sense of a protocol message, not a human readable message] to a buffer provided by the application. However, this message can be extended relatively easily to include the string information, but the syscall/prctl wouldn't work since the syscalls didn't actually fail.
However, it could possibly help with the namespace/module issue if you also store THIS_MODULE (or perhaps instead a pointer to the module's error table) in the task. Again not in the netlink case though, I think, that will always require special handling [although there it could be stored away in the socket or so, similar to the task]
johannes
| |