linux-kernel - Re: [PATCH v4] introduce macro spin_event

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 12 Mar 2009 08:58:42 +1100
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Timur Tabi <timur@...escale.com>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>, linux-kernel@...r.kernel.org,
	rdreier@...co.com, jirislaby@...il.com, peterz@...radead.org,
	will.newton@...il.com, hancockrwd@...il.com, jeremy@...p.org
Subject: Re: [PATCH v4] introduce macro spin_event_timeout()

On Wed, 2009-03-11 at 13:18 -0500, Timur Tabi wrote:
> Alan Cox wrote:
> >> Are you talking about the udelay() inside the loop?  If so, I agree
> >> that this is bad and have removed it in the PowerPC-specific version:
> > 
> > The behaviour you want there is system specific - 10uS is a minimum
> > politeness value for x86 PCI bus for example.
> 
> So we need to allow for delays between successive rights?  We can
> provide that with a third parameter to the macro.

I prefer Alan's method of having the macro be followed by { and } so we
can add things in there. The delay between access will often be somewhat
platform or device specific, and some drivers might be able to do useful
things while spinning.

The other big advantage of that approach is that drivers that aren't in
an atomic section can use msleep() and allow the kernel to schedule on
that processor.

> Is there an architecture-independent method for reading a timebase
> register that's not jiffies?

Not really since there isn't an architecture independent "timebase
register" anyway. But Jiffies for the timeout value doesn't sound
necessarily -that- bad.

Cheers,
Ben.

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