linux-kernel - Re: [PATCH 1/4] Blackfin: arch patch for 2.6.18

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:	Mon, 25 Sep 2006 11:26:17 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Aubrey <aubreylee@...il.com>
Cc:	"Luke Yang" <luke.adi@...il.com>, linux-kernel@...r.kernel.org,
	"Andrew Morton" <akpm@...l.org>
Subject: Re: [PATCH 1/4] Blackfin: arch patch for 2.6.18

On Monday 25 September 2006 09:49, Aubrey wrote:
> Oh, sorry for my unclear description, any of the peripherals can be configured
> to wake up the core from its idled state to process the interrupt on
> Blackfin. I should say __if no other interrupts__ here is the timer
> interrupt waking up the processor every one jiffy.

And that works if interrupts are disabled as it should?

> I don't understand if interrupt occurs between need_resched() and the
> idle instruction, what will become the racy object? Can you comment it
> detailed? thanks.

It's the same problem as why sleep_on() is wrong and wait_event() is
right, you can find lots of documentation about that.

Think about a process calling nanosleep() to wait for a timeout.
It eventually ends up going to sleep and the kernel schedules
the idle task.

The idle task checks need_resched(), which returns false, so it
will call the idle instruction. Before it gets there, the timer
tick happens, which calls the timer softirq. That softirq notices
that the user process should continue running and calls wake_up(),
which makes the condition for need_resched() true.

Since we're handling that softirq that interrupted the idle task,
that task continues what it was last doing and calls the idle instruction.
This is the point where it goes wrong, because your user task should
run, but the CPU is sleeping until the next interrupt happens.

Note that you should in the future disable timer ticks during the
idle function (CONFIG_NO_IDLE_HZ or similar) to save more power, but
in that case the CPU may be in idle indefinitely after missing the
one interrupt that should have woken it up.

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