linux-kernel - Re: Problem with set_current

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>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 15 Oct 2008 17:16:18 +0200
From:	Gilad Ben-Yossef <gilad@...efidence.com>
To:	Peter Teoh <htmldeveloper@...il.com>
CC:	LKML <linux-kernel@...r.kernel.org>
Subject: Re: Problem with set_current_state() and schedule()

Peter Teoh wrote:

> I am puzzled over this:
>
> The module just consist of three function:
>
> static int myfunction(void)
> {
>        dbg("%s - enter....", __FUNCTION__);
>
>        while (!kthread_should_stop()) {
>                dbg("%s - executing....", __FUNCTION__);
>                set_current_state(TASK_INTERRUPTIBLE);
>                printk("sssssssssssssssssssssssssssssssss\n");
>
>
>                schedule(); ======>       ////// removed for part 2
>                printk("sssssssssssssssssssssssssssssssss\n");======>//////
> removed for part 2
>
>
>                msleep(1000);
>                schedule();
>        }
>        return 0;
>        dbg("%s exit", __FUNCTION__);
> ...
>   
> For part 1:
>
> After printing one line, the program never seemed to continue anymore.
>   why?   It got stuck in the first schedule().
>   
You set the state of your task to TASK_INTERRUPTIBLE, that is, not valid 
to run and then call scheduler to give control to some other task. You 
don't include any code that actually sets the task state back to 
TASK_RUNNING, that is legible for scheduling so the schedule will never 
enter your task again. It effectively sleeps for ever.

You either need to use schedule_timeout with some delay or have some 
other means to set your task state back to TASK_RUNNING or better yet, 
use wait_event and friends and don't call schedule() directly.

> For part 2:
>
> Just remove the "remove for part 2".   And u can immediately see that
> it starts to loop forever.   So effectively there is only one
> schedule() in the while loop.
>   

> Why?
>   
Thats' because msleep() changes your task state to TASK_RUNNING when it 
finishes sleeping, so you're calling the scheduler with a TASK_RUNNING 
state and it will schedule your task back sometime (perhaps even 
immediately).
> I am quite puzzled......thanks in advance for the help.   :-).
>
>   
Go read chapter 7 of "Linux Device Drivers, Third Edition" :-)

Gilad


-- 
Gilad Ben-Yossef 
Chief Coffee Drinker

Codefidence Ltd.
The code is free, your time isn't.(TM)

Web:    http://codefidence.com
Email:  gilad@...efidence.com
Office: +972-8-9316883 ext. 201
Fax:    +972-8-9316885
Mobile: +972-52-8260388

	The Doctor: Don't worry, Reinette, just a nightmare. 
	Everyone has nightmares. Even monsters from under the 
	bed have nightmares, don't you, monster?
	Reinette: What do monsters have nightmares about?
	The Doctor: Me! 

--
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/