linux-kernel - Re: [KJ] [patch] fix common mistake in polling loops

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: <82faac5b0608061639v315c6fa9l17cd4bf44b6bbc51@mail.gmail.com>
Date:	Mon, 7 Aug 2006 09:39:54 +1000
From:	"Darren Jenkins" <darrenrjenkins@...il.com>
To:	"Pavel Machek" <pavel@....cz>
Cc:	"Zed 0xff" <zed.0xff@...il.com>, kernel-janitors@...l.org,
	linux-kernel@...r.kernel.org
Subject: Re: [KJ] [patch] fix common mistake in polling loops

G'day

On 8/5/06, Pavel Machek <pavel@....cz> wrote:

> > Well, whoever wrote thi has some serious problems (in attitude
> > department). *Any* loop you design may take half a minute under
> > streange circumstances.

6.
common mistake in polling loops [from Linus]:

>
> Actually it may be broken, depending on use. In some cases this loop
> may want to poll the hardware 50 times, 10msec appart... and your loop
> can poll it only once in extreme conditions.
>
> Actually your loop is totally broken, and may poll only once (without
> any delay) and then directly timeout :-P -- that will break _any_
> user.

The Idea is that we are checking some event in external hardware that
we know will complete in a given time (This time is not dependant on
system activity but is fixed). After that time if the event has not
happened we know something has borked.
So in the loop, after the time period has expired without the event
happening we can go and clean up and get ready to go again, without
bothering to poll any more, because we already know something has
borked.

What does this give you ? Well it can improve performance by speeding
up re-try's when under heavy system load. The cost of cause is code
complexity.

Darren J.
-
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/