linux-toradex.git/include/asm-generic/unistd.h, branch v3.4.99

compat: use sys_sendfile64() implementation for sendfile syscall

2012-03-27T17:36:57+00:00

 was set up to use sys_sendfile() for the 32-bit
compat API instead of sys_sendfile64(), but in fact the right thing to
do is to use sys_sendfile64() in all cases.  The 32-bit sendfile64() API
in glibc uses the sendfile64 syscall, so it has to be capable of doing
full 64-bit operations.  But the sys_sendfile() kernel implementation
has a MAX_NON_LFS test in it which explicitly limits the offset to 2^32.
So, we need to use the sys_sendfile64() implementation in the kernel
for this case.

Cc: 
Acked-by: Arnd Bergmann 
Signed-off-by: Chris Metcalf

asm-generic/unistd.h: support new process_vm_{readv,write} syscalls

2011-12-03T20:31:48+00:00

Also prototype the "compat" functions so they can be referenced
from C code.

Signed-off-by: Chris Metcalf 
Acked-by: Arnd Bergmann

All Arch: remove linkage for sys_nfsservctl system call

2011-08-26T22:09:58+00:00

The nfsservctl system call is now gone, so we should remove all
linkage for it.

Signed-off-by: NeilBrown 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Linus Torvalds

asm-generic/unistd.h: support sendmmsg syscall

2011-06-02T18:31:38+00:00

Signed-off-by: Chris Metcalf 
Acked-by: Arnd Bergmann

ns: Wire up the setns system call

2011-05-28T17:48:39+00:00

32bit and 64bit on x86 are tested and working.  The rest I have looked
at closely and I can't find any problems.

setns is an easy system call to wire up.  It just takes two ints so I
don't expect any weird architecture porting problems.

While doing this I have noticed that we have some architectures that are
very slow to get new system calls.  cris seems to be the slowest where
the last system calls wired up were preadv and pwritev.  avr32 is weird
in that recvmmsg was wired up but never declared in unistd.h.  frv is
behind with perf_event_open being the last syscall wired up.  On h8300
the last system call wired up was epoll_wait.  On m32r the last system
call wired up was fallocate.  mn10300 has recvmmsg as the last system
call wired up.  The rest seem to at least have syncfs wired up which was
new in the 2.6.39.

v2: Most of the architecture support added by Daniel Lezcano 
v3: ported to v2.6.36-rc4 by: Eric W. Biederman 
v4: Moved wiring up of the system call to another patch
v5: ported to v2.6.39-rc6
v6: rebased onto parisc-next and net-next to avoid syscall  conflicts.
v7: ported to Linus's latest post 2.6.39 tree.

>  arch/blackfin/include/asm/unistd.h     |    3 ++-
>  arch/blackfin/mach-common/entry.S      |    1 +
Acked-by: Mike Frysinger 

Oh - ia64 wiring looks good.
Acked-by: Tony Luck 

Signed-off-by: Eric W. Biederman 
Signed-off-by: Linus Torvalds

compat: fixes to allow working with tile arch

2011-05-12T19:51:36+00:00

The existing  mechanism doesn't really provide
enough to create the 64-bit "compat" ABI properly in a generic way,
since the compat ABI is a mix of things were you can re-use the 64-bit
versions of syscalls and things where you need a compat wrapper.

To provide this in the most direct way possible, I added two new macros
to go along with the existing __SYSCALL and __SC_3264 macros: __SC_COMP
and SC_COMP_3264.  These macros take an additional argument, typically a
"compat_sys_xxx" function, which is passed to __SYSCALL if you define
__SYSCALL_COMPAT when including the header, resulting in a pointer to
the compat function being placed in the generated syscall table.

The change also adds some missing definitions to  so that
it actually has declarations for all the compat syscalls, since the
"[nr] = ##call" approach requires proper C declarations for all the
functions included in the syscall table.

Finally, compat.c defines compat_sys_sigpending() and
compat_sys_sigprocmask() even if the underlying architecture doesn't
request it, which tries to pull in undefined compat_old_sigset_t defines.
We need to guard those compat syscall definitions with appropriate
__ARCH_WANT_SYS_xxx ifdefs.

Acked-by: Arnd Bergmann 
Signed-off-by: Chris Metcalf

include/asm-generic/unistd.h: fix syncfs syscall number

2011-03-23T00:43:58+00:00

syncfs() is duplicating name_to_handle_at() due to a merging mistake.

Cc: Sage Weil 
Cc: Al Viro 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

introduce sys_syncfs to sync a single file system

2011-03-21T04:40:29+00:00

It is frequently useful to sync a single file system, instead of all
mounted file systems via sync(2):

 - On machines with many mounts, it is not at all uncommon for some of
   them to hang (e.g. unresponsive NFS server).  sync(2) will get stuck on
   those and may never get to the one you do care about (e.g., /).
 - Some applications write lots of data to the file system and then
   want to make sure it is flushed to disk.  Calling fsync(2) on each
   file introduces unnecessary ordering constraints that result in a large
   amount of sub-optimal writeback/flush/commit behavior by the file
   system.

There are currently two ways (that I know of) to sync a single super_block:

 - BLKFLSBUF ioctl on the block device: That also invalidates the bdev
   mapping, which isn't usually desirable, and doesn't work for non-block
   file systems.
 - 'mount -o remount,rw' will call sync_filesystem as an artifact of the
   current implemention.  Relying on this little-known side effect for
   something like data safety sounds foolish.

Both of these approaches require root privileges, which some applications
do not have (nor should they need?) given that sync(2) is an unprivileged
operation.

This patch introduces a new system call syncfs(2) that takes an fd and
syncs only the file system it references.  Maybe someday we can

 $ sync /some/path

and not get

 sync: ignoring all arguments

The syscall is motivated by comments by Al and Christoph at the last LSF.
syncfs(2) seems like an appropriate name given statfs(2).

A similar ioctl was also proposed a while back, see
	http://marc.info/?l=linux-fsdevel&m=127970513829285&w=2

Signed-off-by: Sage Weil 
Signed-off-by: Al Viro

asm-generic: support clock_adjtime() in

2011-03-20T04:09:20+00:00

A syscall was added without being added to asm-generic, which
makes tile (and presumably score and unicore32) break.

Signed-off-by: Chris Metcalf 
Acked-by: Arnd Bergmann 
Cc: Guan Xuetao 
Cc: Chen Liqin 
Cc: Lennox Wu

unistd.h: Add new syscalls numbers to asm-generic

2011-03-15T06:21:45+00:00

Signed-off-by: Aneesh Kumar K.V 
Signed-off-by: Al Viro