linux-kernel - Re: [patch 05/11] 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 for Android: free password hash cracker in your pocket

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

Message-ID: <20070214223216.GA7616@elte.hu>
Date:	Wed, 14 Feb 2007 23:32:16 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Alan <alan@...rguk.ukuu.org.uk>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Arjan van de Ven <arjan@...radead.org>,
	Christoph Hellwig <hch@...radead.org>,
	Andrew Morton <akpm@....com.au>,
	Ulrich Drepper <drepper@...hat.com>,
	Zach Brown <zach.brown@...cle.com>,
	Evgeniy Polyakov <johnpol@....mipt.ru>,
	"David S. Miller" <davem@...emloft.net>,
	Benjamin LaHaise <bcrl@...ck.org>,
	Suparna Bhattacharya <suparna@...ibm.com>,
	Davide Libenzi <davidel@...ilserver.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [patch 05/11] syslets: core code

* Alan <alan@...rguk.ukuu.org.uk> wrote:

> >    this "AIO atom" in the first place, WHICH WE KNOW IS INCORRECT, 
> >    since current users use "aio_read()" that simply doesn't have 
> >    that and doesn't build up any such data structures.
> 
> Do current users do this because that is all they have, because it is 
> hard, or because the current option is all that makes sense ?
> 
> The ability to avoid asynchronous completion waits and 
> complete/wake/despatch cycles is a good thing of itself. [...]

yeah, that's another key thing. I do plan to provide a sys_upcall() 
syscall as well which calls a 5-parameter user-space function with a 
special stack. (it's like a lightweight signal/event handler, without 
any of the signal handler legacies and overhead - it's like a reverse 
system call - a "user call". Obviously pure userspace would never use 
sys_upcall(), unless as an act of sheer masochism.)

[ that way say a full HTTP request could be done by an asynchronous
  context, because the HTTP parser could be done as a sys_upcall(). ]

so if it's simpler/easier for a syslet to do a step in user-space - as 
long as it's an 'atom' of processing - it can be done.

or if processing is so heavily in user-space that most of the logic 
lives there then just use plain pthreads. There's just no point in 
moving complex user-space code to the syslet side if it's easier/faster 
to do it in user-space. Syslets are there for asynchronous /kernel/ 
execution, and is centered around how the kernel does stuff: system 
calls.

besides sys_upcall() i also plan two other extensions:

 - a CLONE_ASYNC_WORKER for user-space to be able use its pthread as an
   optional worker thread in the async engine. A thread executing
   user-space code qualifies as a 'busy' thread - it has to call into
   sys_async_cachemiss_thread() to 'offer' itself as a ready thread that
   the 'head' could switch to anytime.

 - support for multiple heads sharing the async context pool. All the
   locking logic is there already (because cachemiss threads can already
   access the queue), it only needs a refcount in struct async_head
   (only accessed during fork/exit), and an update to the teardown logic
   (that too is a slowpath).

	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/