linux-kernel - Re: is minimum udelay() not respected in preemptible SMP kernel-2.6.23?

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: <200711081324.49130.mitov@issp.bas.bg>
Date:	Thu, 8 Nov 2007 13:24:49 +0200
From:	Marin Mitov <mitov@...p.bas.bg>
To:	linux-kernel@...r.kernel.org
Subject: Re: is minimum udelay() not respected in preemptible SMP kernel-2.6.23?

Hi all,

Thanks to all of you answering to my post.

On 7.11.2007, Andrew Morton wrote:
> Ow.  Yes, from my reading delay_tsc() can return early (or after
> heat-death-of-the-universe) if the TSCs are offset and if preemption
> migrates the calling task between CPUs.
>
> I suppose a lameo fix would be to disable preemption in delay_tsc().

I have seen the problem in delay_tsc(), but I was pusled by these lines
in my dmesg:

> Time: acpi_pm clocksource has been installed.
> Switched to high resolution mode on CPU 0
> Switched to high resolution mode on CPU 1

I thought (sort of) acpi_pm (but not tsc) is used in udelay().

The same delay_tsc() is used in both arches: i386 & x86_64
(and as I see from the proposed patches in -mm, also for 
the new x86 arch). Should the patch be applied for all of them?

Quite similar function ia64_itc_udelay() is used in IA64, but one
find a coment before it:
/*
 * Generic udelay assumes that if preemption is allowed and the thread
 * migrates to another CPU, that the ITC values are synchronized across
 * all CPUs.
 */

Are they really synchronized or similar patch: preempt_disable/enable()
should be applied?

What about all other arches?

Thanks.

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