linux-kernel - Re: General kernel question about waiting for events

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, 02 Dec 2009 03:28:32 +0200
From:	Maxim Levitsky <maximlevitsky@...il.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: General kernel question about waiting for events

On Wed, 2009-12-02 at 00:24 +0000, Alan Cox wrote: 
> > In that case, wrapped in different packages, it always ends with
> > following loop:
> > 
> > while( event == false )
> > schedule();
> 
> No. If it were to do that then real time processes could spin eating the
> CPU forever.
> 
> There is a difference between rescheduling and sleeping for an event.
> Sleeping for an event (ie on a waitqueue) means that you will not be
> woken until the wait queue is woken (or certain other things like signals
> if interruptible). Rescheduling gives the CPU to someone else if anyone
> wants it.
> 
> In short the different task states that are set are the important bit to
> look at to understand this further.
Thanks you very much!

I already begin to investigate in that area, but your answer sums
everything up, sorry for silly (as I expected) question.

So, current task state is set to TASK_UNINTERRUPTIBLE or
TASK_INTERRUPTIBLE which differ in signal delivery (that I understood,
the TASK_INTERRUPTIBLE will break the wait when signal is received) but
both mean that current task is removed from scheduler pool until it is
woken up, or in case of schedule_timeout() also after the timeout
expires.
Also wait_event_interruptible_timeout does check the condition to avoid
useless sleeps, but if another thread or interrupt handler want to wake
it up, it not only sets that condition (it is optional at all) but
actually wakes the task up using literally wake_up() or related
functions.

Best regards,
Maxim Levitsky

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