jan.kiszka at siemens.com
Mon Jul 16 16:20:50 CEST 2018
On 2018-07-13 19:48, Jan Kiszka wrote:
> Hi all,
> this pattern causes a kernel crash:
> int main()
> struct sched_param schedpar;
> schedpar.sched_priority = 1;
> pthread_setschedparam(pthread_self(), SCHED_FIFO, &schedpar);
> pthread_setschedparam(0x1234, SCHED_FIFO, &schedpar);
> return 0;
> The second, invalid setschedparam makes the core try to shadow the
> current thread - which is already shadowed - and that fails and then
> causes a failure in the error cleanup path. But one after the other.
> The semantic of pthread_setschedparam(unknown_remote_thread) should be
> to just invoke the plain glibc function for that thread. But right now
> the core's pthread_setschedparam_ex has no chance to tell a request to
> promote the current thread to a shadow apart from a request on an
> unknown (or invalid) remote thread ID. We would need to extend the
> syscall ABI for that, I'm afraid (pass down pthread_self() as well). Any
> better ideas?
Turned out that there is simple, ABI-compatible solution: pass NULL as
u_winoff in case the target thread ID is not one of the caller.
Preparing patches, ...
> The actual crash I'm seeing is related to cobalt_thread_shadow() running
> over primary mode, failing with cobalt_map_user() (obviously), and then
> calling pthread_discard() -> __xnthread_discard() which finally detects
> the wrong caller mode. I guess we want secondary_mode_only() also in
> cobalt_map_user() or cobalt_thread_shadow().
...also to harden the kernel against that issue.
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
More information about the Xenomai