linux-kernel - Re: [Uclinux-dist-devel] [ltt-dev] [RFC git tree] Userspace RCU (urcu) for Linux (repost)

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: <8bd0f97a0902131915w37431976j873107d9876aca3d@mail.gmail.com>
Date:	Fri, 13 Feb 2009 22:15:03 -0500
From:	Mike Frysinger <vapier.adi@...il.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Mathieu Desnoyers <compudj@...stal.dyndns.org>,
	Nick Piggin <nickpiggin@...oo.com.au>,
	linux-kernel@...r.kernel.org, ltt-dev@...ts.casi.polymtl.ca,
	uclinux-dist-devel@...ckfin.uclinux.org,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Subject: Re: [Uclinux-dist-devel] [ltt-dev] [RFC git tree] Userspace RCU 
	(urcu) for Linux (repost)

On Fri, Feb 13, 2009 at 13:09, Linus Torvalds wrote:
> Btw, for user space, if you want to do this all right for something like
> BF. I think the only _correct_ thing to do (in the sense that the end
> result will actually be debuggable) is to essentially give full SMP
> coherency in user space.
>
> It's doable, but rather complicated, and I'm not 100% sure it really ends
> up making sense. The way to do it is to just simply say:
>
>  - never map the same page writably on two different cores, and always
>   flush the cache (on the receiving side) when you switch a page from one
>   core to another.
>
> Now, the kernel can't really do that reasonably, but user space possibly could.
>
> Now, I realize that blackfin doesn't actually even have a MMU or a TLB, so
> by "mapping the same page" in that case we end up really meaning "having a
> shared mapping or thread". I think that _should_ be doable. The most
> trivial approach might be to simply limit all processes with shared
> mappings or CLONE_VM to core 0, and letting core 1 run everything else
> (but you could do it differently: mapping something with MAP_SHARED would
> force you to core 0, but threads would just force the thread group to
> stay on _one_ core, rather than necessarily a fixed one).
>
> Yeah, because of the lack of real memory protection, the kernel can't
> _know_ that processes don't behave badly and access things that they
> didn't explicitly map, but I'm hoping that that is rare.
>
> And yes, if you really want to use threads as a way to do something
> across cores, you'd be screwed - the kenrel would only schedule the
> threads on one CPU. But considering the undefined nature of threading on
> such a cpu, wouldn't that still be preferable? Wouldn't it be nice to have
> the knowledge that user space _looks_ cache-coherent by virtue of the
> kernel just limiting cores appropriately?

the BF pseudo SMP does not allow threaded processes to run on multiple
cores simultaneously because of this desync crap.

well, the BF hardware does have optional memory protection, but the
overhead is often too great for most people.  it performs well enough
to do debugging, but not for people trying to multimedia and other fun
stuff.
-mike
--
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/