linux-stable.git/arch/x86/syscalls, branch v3.7

Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/signal

2012-10-10T03:02:25+00:00

Pull generic execve() changes from Al Viro:
 "This introduces the generic kernel_thread() and kernel_execve()
  functions, and switches x86, arm, alpha, um and s390 over to them."

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/signal: (26 commits)
  s390: convert to generic kernel_execve()
  s390: switch to generic kernel_thread()
  s390: fold kernel_thread_helper() into ret_from_fork()
  s390: fold execve_tail() into start_thread(), convert to generic sys_execve()
  um: switch to generic kernel_thread()
  x86, um/x86: switch to generic sys_execve and kernel_execve
  x86: split ret_from_fork
  alpha: introduce ret_from_kernel_execve(), switch to generic kernel_execve()
  alpha: switch to generic kernel_thread()
  alpha: switch to generic sys_execve()
  arm: get rid of execve wrapper, switch to generic execve() implementation
  arm: optimized current_pt_regs()
  arm: introduce ret_from_kernel_execve(), switch to generic kernel_execve()
  arm: split ret_from_fork, simplify kernel_thread() [based on patch by rmk]
  generic sys_execve()
  generic kernel_execve()
  new helper: current_pt_regs()
  preparation for generic kernel_thread()
  um: kill thread->forking
  um: let signal_delivered() do SIGTRAP on singlestepping into handler
  ...

UAPI: Plumb the UAPI Kbuilds into the user header installation and checking

2012-10-02T17:01:57+00:00

Plumb the UAPI Kbuilds into the user header installation and checking system.
As the headers are split the entries will be transferred across from the old
Kbuild files to the UAPI Kbuild files.

The changes made in this commit are:

 (1) Exported generated files (of which there are currently four) are moved to
     uapi/ directories under the appropriate generated/ directory, thus we
     get:

	include/generated/uapi/linux/version.h
	arch/x86/include/generated/uapi/asm/unistd_32.h
	arch/x86/include/generated/uapi/asm/unistd_64.h
	arch/x86/include/generated/uapi/asm/unistd_x32.h

     These paths were added to the build as -I flags in a previous patch.

 (2) scripts/Makefile.headersinst is now given the UAPI path to install from
     rather than the old path.

     It then determines the old path from that and includes that Kbuild also
     if it exists, thus permitting the headers to exist in either directory
     during the changeover.

     I also renamed the "install" variable to "installdir" as it refers to a
     directory not the install program.

 (3) scripts/headers_install.pl is altered to take a list of source file paths
     instead of just their names so that the makefile can tell it exactly
     where to find each file.

     For the moment, files can be obtained from one of four places for each
     output directory:

	.../include/uapi/foo/
	.../include/generated/uapi/foo/
	.../include/foo/
	.../include/generated/foo/

     The non-UAPI paths will be dropped later.

Signed-off-by: David Howells 
Acked-by: Arnd Bergmann 
Acked-by: Thomas Gleixner 
Acked-by: Paul E. McKenney 
Acked-by: Dave Jones

UAPI: x86: Differentiate the generated UAPI and internal headers

2012-10-02T17:01:56+00:00

Differentiate the generated UAPI and internal headers during generation such
that the UAPI headers can be installed elsewhere.

A later patch will use this to move the UAPI headers to:

	arch/x86/include/generated/uapi/asm/

to make them easier to handle.

A previous patch added a -I for this path.

Signed-off-by: David Howells 
Acked-by: Arnd Bergmann 
Acked-by: Thomas Gleixner 
Acked-by: Paul E. McKenney 
Acked-by: Dave Jones

x86, um/x86: switch to generic sys_execve and kernel_execve

2012-10-01T02:53:32+00:00

32bit wrapper is lost on that; 64bit one is *not*, since
we need to arrange for full pt_regs on stack when we call
sys_execve() and we need to load callee-saved ones from
there afterwards.

Signed-off-by: Al Viro

x32: Use compat shims for {g,s}etsockopt

2012-08-18T21:15:39+00:00

Some of the arguments to {g,s}etsockopt are passed in userland pointers.
If we try to use the 64bit entry point, we end up sometimes failing.

For example, dhcpcd doesn't run in x32:
	# dhcpcd eth0
	dhcpcd[1979]: version 5.5.6 starting
	dhcpcd[1979]: eth0: broadcasting for a lease
	dhcpcd[1979]: eth0: open_socket: Invalid argument
	dhcpcd[1979]: eth0: send_raw_packet: Bad file descriptor

The code in particular is getting back EINVAL when doing:
	struct sock_fprog pf;
	setsockopt(s, SOL_SOCKET, SO_ATTACH_FILTER, &pf, sizeof(pf));

Diving into the kernel code, we can see:
include/linux/filter.h:
	struct sock_fprog {
		unsigned short len;
		struct sock_filter __user *filter;
	};

net/core/sock.c:
	case SO_ATTACH_FILTER:
		ret = -EINVAL;
		if (optlen == sizeof(struct sock_fprog)) {
			struct sock_fprog fprog;

			ret = -EFAULT;
			if (copy_from_user(&fprog, optval, sizeof(fprog)))
				break;

			ret = sk_attach_filter(&fprog, sk);
		}
		break;

arch/x86/syscalls/syscall_64.tbl:
	54 common setsockopt sys_setsockopt
	55 common getsockopt sys_getsockopt

So for x64, sizeof(sock_fprog) is 16 bytes.  For x86/x32, it's 8 bytes.
This comes down to the pointer being 32bit for x32, which means we need
to do structure size translation.  But since x32 comes in directly to
sys_setsockopt, it doesn't get translated like x86.

After changing the syscall table and rebuilding glibc with the new kernel
headers, dhcp runs fine in an x32 userland.

Oddly, it seems like Linus noted the same thing during the initial port,
but I guess that was missed/lost along the way:
	https://lkml.org/lkml/2011/8/26/452

[ hpa: tagging for -stable since this is an ABI fix. ]

Bugzilla: https://bugs.gentoo.org/423649
Reported-by: Mads 
Signed-off-by: Mike Frysinger 
Link: http://lkml.kernel.org/r/1345320697-15713-1-git-send-email-vapier@gentoo.org
Cc: H. J. Lu 
Cc:  v3.4..v3.5
Signed-off-by: H. Peter Anvin

x86-64, kcmp: The kcmp system call can be common

2012-08-01T23:01:06+00:00

We already use the same system call handler for i386 and x86-64, there
is absolutely no reason x32 can't use the same system call, too.

Signed-off-by: H. Peter Anvin 
Cc: H.J. Lu 
Cc: Cyrill Gorcunov 
Cc:  v3.5
Link: http://lkml.kernel.org/n/tip-vwzk3qbcr3yjyxjg2j38vgy9@git.kernel.org

syscalls, x86: add __NR_kcmp syscall

2012-06-01T00:49:32+00:00

While doing the checkpoint-restore in the user space one need to determine
whether various kernel objects (like mm_struct-s of file_struct-s) are
shared between tasks and restore this state.

The 2nd step can be solved by using appropriate CLONE_ flags and the
unshare syscall, while there's currently no ways for solving the 1st one.

One of the ways for checking whether two tasks share e.g.  mm_struct is to
provide some mm_struct ID of a task to its proc file, but showing such
info considered to be not that good for security reasons.

Thus after some debates we end up in conclusion that using that named
'comparison' syscall might be the best candidate.  So here is it --
__NR_kcmp.

It takes up to 5 arguments - the pids of the two tasks (which
characteristics should be compared), the comparison type and (in case of
comparison of files) two file descriptors.

Lookups for pids are done in the caller's PID namespace only.

At moment only x86 is supported and tested.

[akpm@linux-foundation.org: fix up selftests, warnings]
[akpm@linux-foundation.org: include errno.h]
[akpm@linux-foundation.org: tweak comment text]
Signed-off-by: Cyrill Gorcunov 
Acked-by: "Eric W. Biederman" 
Cc: Pavel Emelyanov 
Cc: Andrey Vagin 
Cc: KOSAKI Motohiro 
Cc: Ingo Molnar 
Cc: H. Peter Anvin 
Cc: Thomas Gleixner 
Cc: Glauber Costa 
Cc: Andi Kleen 
Cc: Tejun Heo 
Cc: Matt Helsley 
Cc: Pekka Enberg 
Cc: Eric Dumazet 
Cc: Vasiliy Kulikov 
Cc: Alexey Dobriyan 
Cc: Valdis.Kletnieks@vt.edu
Cc: Michal Marek 
Cc: Frederic Weisbecker 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Merge branch 'x86-x32-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2012-03-30T01:12:23+00:00

Pull x32 support for x86-64 from Ingo Molnar:
 "This tree introduces the X32 binary format and execution mode for x86:
  32-bit data space binaries using 64-bit instructions and 64-bit kernel
  syscalls.

  This allows applications whose working set fits into a 32 bits address
  space to make use of 64-bit instructions while using a 32-bit address
  space with shorter pointers, more compressed data structures, etc."

Fix up trivial context conflicts in arch/x86/{Kconfig,vdso/vma.c}

* 'x86-x32-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (71 commits)
  x32: Fix alignment fail in struct compat_siginfo
  x32: Fix stupid ia32/x32 inversion in the siginfo format
  x32: Add ptrace for x32
  x32: Switch to a 64-bit clock_t
  x32: Provide separate is_ia32_task() and is_x32_task() predicates
  x86, mtrr: Use explicit sizing and padding for the 64-bit ioctls
  x86/x32: Fix the binutils auto-detect
  x32: Warn and disable rather than error if binutils too old
  x32: Only clear TIF_X32 flag once
  x32: Make sure TS_COMPAT is cleared for x32 tasks
  fs: Remove missed ->fds_bits from cessation use of fd_set structs internally
  fs: Fix close_on_exec pointer in alloc_fdtable
  x32: Drop non-__vdso weak symbols from the x32 VDSO
  x32: Fix coding style violations in the x32 VDSO code
  x32: Add x32 VDSO support
  x32: Allow x32 to be configured
  x32: If configured, add x32 system calls to system call tables
  x32: Handle process creation
  x32: Signal-related system calls
  x86: Add #ifdef CONFIG_COMPAT to 
  ...

x86-32: Fix typo for mq_getsetattr in syscall table

2012-03-22T19:42:41+00:00

Syscall 282 was mistakenly named mq_getsetaddr instead of mq_getsetattr.
When building uClibc against the Linux kernel this would result in a
shared library that doesn't provide the mq_getattr() and mq_setattr()
functions.

Signed-off-by: Thierry Reding 
Link: http://lkml.kernel.org/r/1332366608-2695-2-git-send-email-thierry.reding@avionic-design.de
Cc:  v3.3
Signed-off-by: H. Peter Anvin

x32: Add ptrace for x32

2012-03-05T23:43:45+00:00

X32 ptrace is a hybrid of 64bit ptrace and compat ptrace with 32bit
address and longs.  It use 64bit ptrace to access the full 64bit
registers.  PTRACE_PEEKUSR and PTRACE_POKEUSR are only allowed to access
segment and debug registers.  PTRACE_PEEKUSR returns the lower 32bits
and PTRACE_POKEUSR zero-extends 32bit value to 64bit.   It works since
the upper 32bits of segment and debug registers of x32 process are always
zero.  GDB only uses PTRACE_PEEKUSR and PTRACE_POKEUSR to access
segment and debug registers.

[ hpa: changed TIF_X32 test to use !is_ia32_task() instead, and moved
  the system call number to the now-unused 521 slot. ]

Signed-off-by: "H.J. Lu" 
Signed-off-by: H. Peter Anvin 
Cc: Roland McGrath 
Cc: Oleg Nesterov 
Link: http://lkml.kernel.org/r/1329696488-16970-1-git-send-email-hpa@zytor.com