linux-kernel - Re: [patch 00/11] ANNOUNCE: "Syslets", generic asynchronous system call support

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, 13 Feb 2007 19:28:56 -0800 (PST)
From:	Davide Libenzi <davidel@...ilserver.org>
To:	Ingo Molnar <mingo@...e.hu>
cc:	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>,
	Benjamin LaHaise <bcrl@...ck.org>,
	Suparna Bhattacharya <suparna@...ibm.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [patch 00/11] ANNOUNCE: "Syslets", generic asynchronous system
 call support

On Tue, 13 Feb 2007, Ingo Molnar wrote:

> I'm pleased to announce the first release of the "Syslet" kernel feature 
> and kernel subsystem, which provides generic asynchrous system call 
> support:
> [...]

Ok, I had little to time review the code, but it has been a long 
working day, so bear with me if I missed something.
I don't see how sys_async_exec would not block, based on your patches. 
Let's try to follow:

- We enter sys_async_exec

- We may fill the pool, but that's nothing interesting ATM. A bunch of 
  threads will be created, and they'll end up sleeping inside the 
  cachemiss_loop

- We set the async_ready pointer and we fall inside exec_atom

- There we copy the atom (nothing interesting from a scheduling POV) and 
  we fall inside __exec_atom

- In __exec_atom we do the actual syscall call. Note that we're still the 
  task/thread that called sys_async_exec

- So we enter the syscall, and now we end up in schedule because we're 
  just unlucky

- We notice that the async_ready pointer is not NULL, and we call 
  __async_schedule

- Finally we're in pick_new_async_thread and we pick one of the ready 
  threads sleeping in cachemiss_loop

- We copy the pt_regs to the newly picked-up thread, we set its async head 
  pointer, we set the current task async_ready pointer to NULL, we 
  re-initialize the async_thread structure (the old async_ready), and we 
  put ourselves in the busy_list

- Then we roll back to the schedule that started everything, and being 
  still "prev" for the scheduler, we go to sleep

So the sys_async_exec task is going to block. Now, am I being really 
tired, or the cachemiss fast return is simply not there?
There's another problem AFAICS:

- We woke up one of the cachemiss_loop threads in pick_new_async_thread

- The threads wakes up, mark itself as busy, and look at the ->work 
  pointer hoping to find something to work on

But we never set that pointer to a userspace atom AFAICS. Me blind? :)




- Davide


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