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]
Date:	Thu, 14 Jan 2010 17:59:39 +1100
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	David Miller <davem@...emloft.net>
Cc:	arnd@...db.de, geert@...ux-m68k.org, acme@...hat.com,
	linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-m68k@...r.kernel.org
Subject: Re: sys_recvmmsg: wire up or not?

On Wed, 2010-01-13 at 20:28 -0800, David Miller wrote:
> > Anything happening here ? We're getting that warning on ppc too
> despite
> > the fact that we use socketcall like x86... Should checksyscall be
> made
> > smarter or the syscall just removed from x86 ? :-)
> 
> I think it's better to trap directly to the system call rather
> than going through yet another demultiplexer.
> 
> I severely regretted using sys_socketcall initially on sparc32
> because it added a few microseconds to socket syscall latency
> (cpus back then were slow :-) 

Oh I definitely agree that a direct syscall is better, and I wonder in
fact if I should add new syscalls in addition to socketcall for powerpc,
for glibc to do a slow migration :-) I was just wondering about the
inconsistency for archs like us who have socketcall today, to also have
to define the syscall ...

IE. I'd rather have them all duplicated into real syscalls than some of
them only in socketcall and some on both since that will make any kind
of userspace transition even more hellish.

Cheers,
Ben.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ