linux-kernel - Re: [patch 06/11] syslets: core, documentation

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:	Wed, 14 Feb 2007 13:06:59 -0800 (PST)
From:	Davide Libenzi <davidel@...ilserver.org>
To:	Benjamin LaHaise <bcrl@...ck.org>
cc:	Russell King <rmk+lkml@....linux.org.uk>,
	Ingo Molnar <mingo@...e.hu>,
	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>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [patch 06/11] syslets: core, documentation

On Wed, 14 Feb 2007, Benjamin LaHaise wrote:

> On Wed, Feb 14, 2007 at 12:14:29PM -0800, Davide Libenzi wrote:
> > I think you may have mis-interpreted my words. *When* a schedule would 
> > block a synco execution try, then you do have a context switch. Noone 
> > argue that, and the code is clear. The sys_async_exec thread will block, 
> > and a newly woke up thread will re-emerge to sys_async_exec with a NULL 
> > returned to userspace. But in a "cachehit" case (no schedule happens 
> > during the syscall/*let execution), there is no context switch at all. 
> > That is the whole point of the optimization.
> 
> And I will repeat myself: that cannot be done.  Tell me how the following 
> what if scenario works: you're in an MMX optimized memory copy and you take 
> a page fault.  How does returning to the submittor of the async operation 
> get the correct MMX state restored?  It doesn't.

Bear with me Ben, and let's follow this up :) If you are in the middle of 
an MMX copy operation, inside the syscall, you are:

- Userspace, on task A, calls sys_async_exec

- Userspace in _not_ doing any MMX stuff before the call

- We execute the syscall

- Task A, executing the syscall and inside an MMX copy operation, gets a 
  page fault

- We get a schedule

- Task A MMX state will *follow* task A, that will be put to sleep

- We wake task B that will return to userspace

So if the MMX work happens inside the syscall execution, we're fine 
because its context will follow the same task being put into sleep.
Problem would be to preserve the *caller* (userspace) context. But than 
can be done in a lazy way (detecting if task A user the FPU) like we're 
currently doing it, once we detect a schedule-out condition. That wouldn't 
be the most common case for many userspace programs in any case.




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