linux-kernel - Re: [PATCHv4 5/6] Allow setting O

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: <20071120222227.GH24156@elte.hu>
Date:	Tue, 20 Nov 2007 23:22:27 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Zach Brown <zach.brown@...cle.com>,
	Ulrich Drepper <drepper@...hat.com>,
	David Miller <davem@...emloft.net>,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	tglx@...utronix.de, torvalds@...ux-foundation.org
Subject: Re: [PATCHv4 5/6] Allow setting O_NONBLOCK flag for new sockets

* H. Peter Anvin <hpa@...or.com> wrote:

> It seems that you're doing the same thing in both cases, except you're 
> now extending it to include other random functionality, which means 
> other things than syslets are suddenly affected.
>
> syslets are arguably a little bit different, since what you're 
> effectively doing there is running a miniature interpreted language in 
> kernel space.  A higher startup overhead should be acceptable, since 
> you're amortizing it over a larger number of calls.  Extending that 
> mechanism suddenly means you HAVE to use that interpreted language 
> message mechanism to access certain system calls, which really does 
> not seem like a good thing neither for performance nor for encouraging 
> sane design of interfaces.

whether that interpreted syslet language survives is still an open 
question - it was extremely ugly when i wrote the first version of it 
and it only got uglier since then :-)

do you suggest that extending the system call calling convention to 
include an arbitrary number of parameters will solve all these API needs 
we have at the moment?

if yes, then a one-shot syslet/async call would in essence be:

	syslet_arg1 ... N, syscall_arg 1 ... M

the same is true for the indirect stuff, we in essence nest syscalls 
inside another syscall:

	sys_indirect arg1 ... N, syscall arg 1 ... M

this all assumes an arbitrarily extendable syscall ABI, which can take 
N+M parameters. Right?

i'm not entirely sure we really want to do this. Nested syscalls would 
have to unpack the arguments and repack them into a kernel-internal call 
format anyway. So there's no performance upside - in fact i can only see 
additional complications.

Why not just pin down the current ABI that there's 6 syscall parameters 
_and not more_? It's totally sensible, and indirection has some minimal 
costs anyway, so copying the nested syscall parameters is a non-issue. 
This is not ad-hoc and when i wrote syslets i actually profiled the 
performance a variable-length calling convention and decided _against_ 
it. Nothing beats the performance of a straight fixd-length copy of 6x4 
(or 6x8) bytes.

The memory access cost argument you mentioned is largely irrelevant and 
inapposite here, this is all passed in on the stack which is well-cached 
in the L1 cache.

	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/