linux-kernel - Re: [patch 04/13] syslets: core code

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: <20070225075946.GA24291@elte.hu>
Date:	Sun, 25 Feb 2007 08:59:46 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Davide Libenzi <davidel@...ilserver.org>
Cc:	Kyle Moffett <mrmacman_g4@....com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Arjan van de Ven <arjan@...radead.org>,
	Christoph Hellwig <hch@...radead.org>,
	Andrew Morton <akpm@....com.au>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Ulrich Drepper <drepper@...hat.com>,
	Zach Brown <zach.brown@...cle.com>,
	Evgeniy Polyakov <johnpol@....mipt.ru>,
	"David S. Miller" <davem@...emloft.net>,
	Suparna Bhattacharya <suparna@...ibm.com>,
	Jens Axboe <jens.axboe@...cle.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [patch 04/13] syslets: core code


* Davide Libenzi <davidel@...ilserver.org> wrote:

> > No, it absolutely is a matter of speed.  The reason to have those 
> > two implemented that way is so that they can be implemented as 
> > vsyscalls completely in userspace.  This means that on most modern 
> > platforms you can implement the "make a threadlet when I block" 
> > semantic without even touching kernel-mode.  The way it's set up all 
> > you'd have to do is save some parameters, set up a new callstack, 
> > and poke a "1" into a memory address in the TLS.  To stop, you 
> > effectively just poke a "0" into the spot in the TLS and either 
> > return or terminate the thread.
> 
> Right. I don't why but I got the implression Ingo's threadlet_exec 
> example was just sketch code to be moved in a syscall. That's why I 
> was talking about a sys_threadlet_exec. But yeah, it makes a lot of 
> sense to turn threadlet_exec in a glibc thing, and play everything in 
> userspace at that point.

yeah, not having to do any extra entry into the kernel at all (in the 
cached case), and to make them in essence equivalent to a function call 
is my plan/hope for threadlets :-)

	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/