linux-kernel - Re: General question about TASK_INTERRUPTIBLE and schedule

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

Date:	Fri, 02 Sep 2011 14:18:11 +0800
From:	Shan Hai <haishan.bai@...il.com>
To:	Yong Zhang <yong.zhang0@...il.com>
CC:	sifram rajas <sifram.rajas@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: General question about TASK_INTERRUPTIBLE and schedule_timeout()

On 09/01/2011 10:09 AM, Yong Zhang wrote:
> On Wed, Aug 31, 2011 at 06:18:19PM +0530, sifram rajas wrote:
>> Hi,
>>
>> I have a general question about the following 2 lines of code I see
>> all over the kernel:
>> 1         set_current_state(TASK_INTERRUPTIBLE) ;
>> 2         schedule_timeout(<some value>);
>>
>> In the above code, if we encounter an interrupt after executing line
>> 1, we will end up
>> call schedule() from the architecture specific code for CONFIG_PREEMPT
>> kernels, after
>> the interrupt handler has been invokled.
> Yes.
>
>> This will cause the current task to sleep interruptibly forever

Actually, sleeping forever in the TASK_INTERRUPTIBLE state is not correct,
because even though the task is preempted by higher priority one
it will finally get a chance to run, but you will get time out value
of <some value> + preemption latency.

>> instead of for a certain timeout interval.
> No.
>
> schedule() will not put an preempted task to sleep, see:

This might be problematic, because on the IRQ to preemption check path
the PREEMPT_ACTIVE was already set and the following 'if' statement
could not hold because of
!(preempt_count() & PREEMPT_ACTIVE) == false

and the pick_next_task() might put the preempted task to sleep.

Correct me on any misunderstanding :-)

Cheers
Shan Hai

> asmlinkage void __sched schduule(void)
> {
> ...
>          if (prev->state&&  !(preempt_count()&  PREEMPT_ACTIVE)) {
>                  if (unlikely(signal_pending_state(prev->state, prev))) {
>                          prev->state = TASK_RUNNING;
>                  } else {
> 		...
> 		}
>          }
> ...
> }
>
> Thanks,
> Yong
>
>> Won't this defeat the purpose of the above code to schedule out or
>> sleep for a certain finite timeout ?
>> If yes, then what are the techniques to solve this problem ?
>>
>>
>> Thanks,
>> Sifram.
>> --
>> 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/

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