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-next>] [day] [month] [year] [list]
Message-ID: <1259712620.23837.22.camel@maxim-laptop>
Date:	Wed, 02 Dec 2009 02:10:20 +0200
From:	Maxim Levitsky <maximlevitsky@...il.com>
To:	linux-kernel <linux-kernel@...r.kernel.org>
Subject: General kernel question about waiting for events

Hi,

I am writing a device driver now, and am am learning to do so at same
time I can say...

I found one interesting feature of the scheduler, and I want to confirm
that I understood it correctly.

Suppose application wants to wait for an event, and doesn't specify any
timeouts.

In that case, wrapped in different packages, it always ends with
following loop:

while( event == false )
schedule();

Now suppose event doesn't happen soon, and system has no other runnable
tasks.

In that case I suspect that system will be in endless loop switching
between idle task (swapper) and this one.

Since its unknown when the event will became true, I don't think that
idle task will be able to put cpu to low power state.

Since on any system there are plenty of tasks that are blocked on
sockets, and don't use any specified timeout, I don't understand how
idle task could run.

I suspect that idle task will run for some predefined time anyway.
It uses need_resched() as an end condition.
But then, am I right that any thread that specifies wait on any event,
will actually force system to wakeup every that 'predefined time'
Which I suspect is 1/HZ seconds?
How longer wait can be done then?

Could you explain that to me a bit?

Another thing I think is wrong is the description for
wait_event_interruptible_timeout

It says, 'sleep until a condition gets true or a timeout elapses',
however it actually tests condition once, sleeps whole timeout, and then
returns.

So a naive user could call that function with large timeout, and think
that as soon as he sets the event, the wait will end.

Am I wrong here?

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ