linux-kernel - Re: [PATCH] port jRCU from 3.3 to 3.4

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:	Tue, 22 May 2012 09:38:58 -0400
From:	Joe Korty <joe.korty@...r.com>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	"stasn77@...il.com" <stasn77@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] port jRCU from 3.3 to 3.4

On Mon, May 21, 2012 at 06:57:44PM -0400, Andi Kleen wrote:
> Joe Korty <joe.korty@...r.com> writes:
> > + *
> > + * jRCU assumes that the frames are large enough that architecture barrier
> > + * operations performed in one frame have fully completed by the start of
> > + * the next.  This period is presumed to be in the tens of microseconds, so
> > + * it may not be wise to run jRCU at a frame rate under 100 usecs.
> 
> This sounds like a very dangerous assumption.

Yeah, I may have to go to a spin lock.  Easy to do, but
I didn't want the serialization that results.  I figured
that with a frame rate of 20 - 1000 Hz it wasn't necessary.

And of course I may not have fully understood all the
nuances of barriers and the memory model.  After all,
spin locks work using pretty much the same techniques and
they don't suffer from any need to delay.

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