linux-kernel - Fwd: Problem with old context in signal handler function

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Wed, 17 Dec 2008 14:06:09 -0800
From:	XComp <xcomp@...or.de>
To:	linux-kernel@...r.kernel.org
Subject: Fwd: Problem with old context in signal handler function


Begin forwarded message:
> From: xcomp@...or.de
> Date: 10. Dezember 2008 17:32:06 GMT-08:00
> To: linux-kernel@...r.kernel.org
> Subject: Problem with old context in signal handler function
>
> Hello everyone,
> I want to switch between user contexts using a signal handler  
> (something like a preemptive scheduler for userlevel threads). I've  
> found several sources, which say that it's not a good idea to use  
> setcontext or swapcontext in a signal handler. Nevertheless there  
> also exists at least one sample code of such an preemptive  
> scheduler, which seems to work well, at least on my machine (Ubuntu  
> 8.04 with linux kernel 2.6.24-22): www.seas.upenn.edu/~cse381/context_demo.c
>
> // [...]
> static ucontext_t thread_context;
> static ucontext_t scheduler_context;
>
> int thread_finished;
> int i;
>
> static void simple_function(void) {
> 	// do nothing but counting
> 	for (i = 0; i < 1000000000; ++i) { }
>
> 	if (i == 1000000000) {
> 		printf("\n[Thread Function]\t1st counting worked fine...");
> 	} else {
> 		printf("\n[Thread Function]\tError: Counting didn't finished  
> (%d)...", i);
> 	}
>
> 	thread_finished = 1;
> }
>
> static void other_function() {
> 	// thread_finished is a global variable, which is set to 1, if the  
> thread function is finished
> 	while(thread_finished != 1) { swapcontext(&scheduler_context,  
> &thread_context); }
> }
>
> static void signal_handler_function(int sig_nr, siginfo_t* info,  
> void *old_context) {
> 	if (sig_nr == SIGPROF) {
> 		// saves the thread context
> 		thread_context = *((ucontext_t*) context);
>
> 		// swaps back to scheduler context
> 		setcontext(&scheduler_context);
> 	}
> }
> // [...]
>
> I ran into the following problem which belongs to the code above. I  
> interrupted simple_function several times by using a ITimer. But the  
> for-loop doesn't finish successfully everytime. Often the if  
> condition is false. But it does not cancel after the first signal is  
> raised. I've found out that using the third parameter old_context  
> for storing the old context is the reason. But I don't know why. So  
> I thought there might be a problem in the kernel. Am I right? I was  
> afraid to post the whole code, so I hope that this code snippet is  
> enough.
> I would appreciate if someone can give me a comment whether this  
> strange behaviour is because of a wrong thinking of mine or because  
> of a error in the kernel which needs to be fixed.
>
> Thanks a lot!
> Matthias

Ok, I try to reduce the problem size. Is it valid to use the  
ucontext_t struct, which is passed through a extended signal handling  
function (3rd argument) in order to get back to this context using  
setcontext(). I think it should. But it causes into strange behaviour  
in some cases (one is explained below). I hope I could make it clear.  
Thanks for any help concerning this problem.

Best,
Matthias
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/