linux-toradex.git/include/uapi/asm-generic, branch v3.15-rc8

asm-generic: Add renameat2 syscall

2014-05-20T08:59:38+00:00

Add the renameat2 syscall to the generic syscall list, which is used by the
following architectures: arc, arm64, c6x, hexagon, metag, openrisc, score,
tile, unicore32.

Signed-off-by: James Hogan 
Acked-by: Arnd Bergmann 
Signed-off-by: Miklos Szeredi 
Cc: linux-arch@vger.kernel.org
Cc: Vineet Gupta 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: linux-arm-kernel@lists.infradead.org
Cc: Mark Salter 
Cc: Aurelien Jacquiot 
Cc: Richard Kuo 
Cc: linux-hexagon@vger.kernel.org
Cc: linux-metag@vger.kernel.org
Cc: Jonas Bonn 
Cc: Chen Liqin 
Cc: Lennox Wu 
Cc: Chris Metcalf 
Cc: Guan Xuetao

asm-generic: remove _STK_LIM_MAX

2014-05-14T23:32:09+00:00

_STK_LIM_MAX could be used to override the RLIMIT_STACK hard limit from
an arch's include/uapi/asm-generic/resource.h file, but is no longer
used since both parisc and metag removed the override. Therefore remove
it entirely, setting the hard RLIMIT_STACK limit to RLIM_INFINITY
directly in include/asm-generic/resource.h.

Signed-off-by: James Hogan 
Cc: Arnd Bergmann 
Cc: linux-arch@vger.kernel.org
Cc: Helge Deller 
Cc: John David Anglin

locks: rename file-private locks to "open file description locks"

2014-04-22T12:23:58+00:00

File-private locks have been merged into Linux for v3.15, and *now*
people are commenting that the name and macro definitions for the new
file-private locks suck.

...and I can't even disagree. The names and command macros do suck.

We're going to have to live with these for a long time, so it's
important that we be happy with the names before we're stuck with them.
The consensus on the lists so far is that they should be rechristened as
"open file description locks".

The name isn't a big deal for the kernel, but the command macros are not
visually distinct enough from the traditional POSIX lock macros. The
glibc and documentation folks are recommending that we change them to
look like F_OFD_{GETLK|SETLK|SETLKW}. That lessens the chance that a
programmer will typo one of the commands wrong, and also makes it easier
to spot this difference when reading code.

This patch makes the following changes that I think are necessary before
v3.15 ships:

1) rename the command macros to their new names. These end up in the uapi
   headers and so are part of the external-facing API. It turns out that
   glibc doesn't actually use the fcntl.h uapi header, but it's hard to
   be sure that something else won't. Changing it now is safest.

2) make the the /proc/locks output display these as type "OFDLCK"

Cc: Michael Kerrisk 
Cc: Christoph Hellwig 
Cc: Carlos O'Donell 
Cc: Stefan Metzmacher 
Cc: Andy Lutomirski 
Cc: Frank Filz 
Cc: Theodore Ts'o 
Signed-off-by: Jeff Layton

madvise: correct the comment of MADV_DODUMP flag

2014-04-07T23:35:58+00:00

s/MADV_NODUMP/MADV_DONTDUMP/

Signed-off-by: Zhang Yanfei 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Merge branch 'locks-3.15' of git://git.samba.org/jlayton/linux

2014-04-04T21:21:20+00:00

Pull file locking updates from Jeff Layton:
 "Highlights:

   - maintainership change for fs/locks.c.  Willy's not interested in
     maintaining it these days, and is OK with Bruce and I taking it.
   - fix for open vs setlease race that Al ID'ed
   - cleanup and consolidation of file locking code
   - eliminate unneeded BUG() call
   - merge of file-private lock implementation"

* 'locks-3.15' of git://git.samba.org/jlayton/linux:
  locks: make locks_mandatory_area check for file-private locks
  locks: fix locks_mandatory_locked to respect file-private locks
  locks: require that flock->l_pid be set to 0 for file-private locks
  locks: add new fcntl cmd values for handling file private locks
  locks: skip deadlock detection on FL_FILE_PVT locks
  locks: pass the cmd value to fcntl_getlk/getlk64
  locks: report l_pid as -1 for FL_FILE_PVT locks
  locks: make /proc/locks show IS_FILE_PVT locks as type "FLPVT"
  locks: rename locks_remove_flock to locks_remove_file
  locks: consolidate checks for compatible filp->f_mode values in setlk handlers
  locks: fix posix lock range overflow handling
  locks: eliminate BUG() call when there's an unexpected lock on file close
  locks: add __acquires and __releases annotations to locks_start and locks_stop
  locks: remove "inline" qualifier from fl_link manipulation functions
  locks: clean up comment typo
  locks: close potential race between setlease and open
  MAINTAINERS: update entry for fs/locks.c

locks: add new fcntl cmd values for handling file private locks

2014-03-31T12:24:43+00:00

Due to some unfortunate history, POSIX locks have very strange and
unhelpful semantics. The thing that usually catches people by surprise
is that they are dropped whenever the process closes any file descriptor
associated with the inode.

This is extremely problematic for people developing file servers that
need to implement byte-range locks. Developers often need a "lock
management" facility to ensure that file descriptors are not closed
until all of the locks associated with the inode are finished.

Additionally, "classic" POSIX locks are owned by the process. Locks
taken between threads within the same process won't conflict with one
another, which renders them useless for synchronization between threads.

This patchset adds a new type of lock that attempts to address these
issues. These locks conflict with classic POSIX read/write locks, but
have semantics that are more like BSD locks with respect to inheritance
and behavior on close.

This is implemented primarily by changing how fl_owner field is set for
these locks. Instead of having them owned by the files_struct of the
process, they are instead owned by the filp on which they were acquired.
Thus, they are inherited across fork() and are only released when the
last reference to a filp is put.

These new semantics prevent them from being merged with classic POSIX
locks, even if they are acquired by the same process. These locks will
also conflict with classic POSIX locks even if they are acquired by
the same process or on the same file descriptor.

The new locks are managed using a new set of cmd values to the fcntl()
syscall. The initial implementation of this converts these values to
"classic" cmd values at a fairly high level, and the details are not
exposed to the underlying filesystem. We may eventually want to push
this handing out to the lower filesystem code but for now I don't
see any need for it.

Also, note that with this implementation the new cmd values are only
available via fcntl64() on 32-bit arches. There's little need to
add support for legacy apps on a new interface like this.

Signed-off-by: Jeff Layton

locks: fix posix lock range overflow handling

2014-03-31T12:24:42+00:00

In the 32-bit case fcntl assigns the 64-bit f_pos and i_size to a 32-bit
off_t.

The existing range checks also seem to depend on signed arithmetic
wrapping when it overflows.  In practice maybe that works, but we can be
more careful.  That also allows us to make a more reliable distinction
between -EINVAL and -EOVERFLOW.

Note that in the 32-bit case SEEK_CUR or SEEK_END might allow the caller
to set a lock with starting point no longer representable as a 32-bit
value.  We could return -EOVERFLOW in such cases, but the locks code is
capable of handling such ranges, so we choose to be lenient here.  The
only problem is that subsequent GETLK calls on such a lock will fail
with EOVERFLOW.

While we're here, do some cleanup including consolidating code for the
flock and flock64 cases.

Signed-off-by: J. Bruce Fields 
Signed-off-by: Jeff Layton

compat: let architectures define __ARCH_WANT_COMPAT_SYS_GETDENTS64

2014-03-04T08:05:33+00:00

For architecture dependent compat syscalls in common code an architecture
must define something like __ARCH_WANT_ if it wants to use the
code.
This however is not true for compat_sys_getdents64 for which architectures
must define __ARCH_OMIT_COMPAT_SYS_GETDENTS64 if they do not want the code.

This leads to the situation where all architectures, except mips, get the
compat code but only x86_64, arm64 and the generic syscall architectures
actually use it.

So invert the logic, so that architectures actively must do something to
get the compat code.

This way a couple of architectures get rid of otherwise dead code.

Signed-off-by: Heiko Carstens

asm-generic: add sched_setattr/sched_getattr syscalls

2014-02-24T11:55:20+00:00

Add the sched_setattr and sched_getattr syscalls to the generic syscall
list, which is used by the following architectures: arc, arm64, c6x,
hexagon, metag, openrisc, score, tile, unicore32.

Signed-off-by: James Hogan 
Acked-by: Arnd Bergmann 
Acked-by: Catalin Marinas 
Cc: linux-arch@vger.kernel.org
Cc: Vineet Gupta 
Cc: Will Deacon 
Cc: linux-arm-kernel@lists.infradead.org
Cc: Mark Salter 
Cc: Aurelien Jacquiot 
Cc: linux-c6x-dev@linux-c6x.org
Cc: Richard Kuo 
Cc: linux-hexagon@vger.kernel.org
Cc: linux-metag@vger.kernel.org
Cc: Jonas Bonn 
Cc: linux@lists.openrisc.net
Cc: Chen Liqin 
Cc: Lennox Wu 
Cc: Chris Metcalf 
Cc: Guan Xuetao

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

2014-01-30T02:22:16+00:00

Pull more x32 uabi type fixes from Peter Anvin:
 "Despite the branch name, **most of these changes are to generic
  code**.  They change types so that they make an increasing amount of
  the exported uapi kernel headers usable for libc.

  The ARM64 people are also interested in these changes for their ILP32
  ABI"

* 'x86-x32-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  uapi: Use __kernel_long_t in struct mq_attr
  uapi: Use __kernel_ulong_t in shmid64_ds/shminfo64/shm_info
  x86, uapi, x32: Use __kernel_ulong_t in x86 struct semid64_ds
  uapi: Use __kernel_ulong_t in struct msqid64_ds
  uapi: Use __kernel_long_t in struct msgbuf
  uapi, asm-generic: Use __kernel_ulong_t in uapi struct ipc64_perm
  uapi: Use __kernel_long_t/__kernel_ulong_t in 
  uapi: Use __kernel_long_t in struct timex