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]

Message-ID: <4E608081.5000107@gmail.com>
Date:	Fri, 02 Sep 2011 15:06:41 +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/02/2011 02:18 PM, Shan Hai wrote:
> 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.
>

I mean when the state of task is TASK_INTERRUPTIBLE the preempted task will
be put to sleep, its true in sifram's case.

Yong is right on stating "schedule() will not put an preempted task to 
sleep",
its true for the task state of which is TASK_RUNNING.

Cheers
Shan Hai

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