linux-kernel - Re: + spinlock_debug-dont-recompute-jiffies_per

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]

Message-ID: <20060725204306.GA22547@elte.hu>
Date:	Tue, 25 Jul 2006 22:43:06 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Dave Jones <davej@...hat.com>, linux-kernel@...r.kernel.org,
	76306.1226@...puserve.com
Subject: Re: + spinlock_debug-dont-recompute-jiffies_per_loop.patch added to -mm tree


* Dave Jones <davej@...hat.com> wrote:

>  > iteration limit, gets recomputed every time.  Caching it explicitly 
>  > prevents that.
> 
> What is the purpose of those __delays being there at all ? Seems odd 
> to be waiting that long when the spinlock could become available a lot 
> sooner.  (These also make spinlock debug really painful on boxes with 
> huge numbers of CPUs).

the debug code has to figure out when to trigger a deadlock warning 
message. If we are looping in a deadlock with irqs disabled on all CPUs, 
there's nothing that advances jiffies. The TSC is not reliable. The 
thing that remains is to use __delay(1). We could calibrate the loop 
separately perhaps?

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