1. 05 Jun, 2018 1 commit
  2. 17 Apr, 2017 11 commits
  3. 02 Mar, 2017 1 commit
  4. 24 Dec, 2016 1 commit
  5. 23 Dec, 2016 1 commit
    • Al Viro's avatar
      move aio compat to fs/aio.c · c00d2c7e
      Al Viro authored
      ... and fix the minor buglet in compat io_submit() - native one
      kills ioctx as cleanup when put_user() fails.  Get rid of
      bogus compat_... in !CONFIG_AIO case, while we are at it - they
      should simply fail with ENOSYS, same as for native counterparts.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      c00d2c7e
  6. 07 Dec, 2016 1 commit
    • Li Wang's avatar
      vfs: fix put_compat_statfs64() does not handle errors · 64d2ab32
      Li Wang authored
      put_compat_statfs64() does NOT return -1 and setting errno to EOVERFLOW
      when some variables(like: f_bsize) overflowed in the returned struct.
      
      The reason is that the ubuf->f_blocks is __u64 type, it couldn't be
      4bits as the judgement in put_comat_statfs64(). Here correct the
      __u32 variables(in struct compat_statfs64) for comparison.
      
      reproducer:
      step1. mount hugetlbfs with two different pagesize on ppc64 arch.
      
      $ hugeadm --pool-pages-max 16M:0
      $ hugeadm --create-mount
      $ mount | grep -i hugetlbfs
      none on /var/lib/hugetlbfs/pagesize-16MB type hugetlbfs (rw,relatime,seclabel,pagesize=16777216)
      none on /var/lib/hugetlbfs/pagesize-16GB type hugetlbfs (rw,relatime,seclabel,pagesize=17179869184)
      
      step2. compile & run this C program.
      
      $ cat statfs64_test.c
      
       #define _LARGEFILE64_SOURCE
       #include <stdio.h>
       #include <sys/syscall.h>
       #include <sys/statfs.h>
      
       int main()
       {
      	struct statfs64 sb;
      	int err;
      
      	err = syscall(SYS_statfs64, "/var/lib/hugetlbfs/pagesize-16GB", sizeof(sb), &sb);
      	if (err)
      		return -1;
      
      	printf("sizeof f_bsize = %d, f_bsize=%ld\n", sizeof(sb.f_bsize), sb.f_bsize);
      
      	return 0;
       }
      
      $ gcc -m32 statfs64_test.c
      $ ./a.out
      sizeof f_bsize = 4, f_bsize=0
      Signed-off-by: default avatarLi Wang <liwang@redhat.com>
      Reviewed-by: default avatarAndreas Dilger <adilger@dilger.ca>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      64d2ab32
  7. 28 Sep, 2016 1 commit
  8. 27 Sep, 2016 1 commit
  9. 02 May, 2016 1 commit
  10. 24 Apr, 2016 1 commit
    • Theodore Ts'o's avatar
      ext4: allow readdir()'s of large empty directories to be interrupted · 1f60fbe7
      Theodore Ts'o authored
      If a directory has a large number of empty blocks, iterating over all
      of them can take a long time, leading to scheduler warnings and users
      getting irritated when they can't kill a process in the middle of one
      of these long-running readdir operations.  Fix this by adding checks to
      ext4_readdir() and ext4_htree_fill_tree().
      
      This was reverted earlier due to a typo in the original commit where I
      experimented with using signal_pending() instead of
      fatal_signal_pending().  The test was in the wrong place if we were
      going to return signal_pending() since we would end up returning
      duplicant entries.  See 9f2394c9 for a more detailed explanation.
      
      Added fix as suggested by Linus to check for signal_pending() in
      in the filldir() functions.
      Reported-by: default avatarBenjamin LaHaise <bcrl@kvack.org>
      Google-Bug-Id: 27880676
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      1f60fbe7
  11. 04 Jan, 2016 1 commit
  12. 31 Oct, 2014 1 commit
  13. 09 Oct, 2014 2 commits
    • Seunghun Lee's avatar
      vfs: move getname() from callers to do_mount() · 5e6123f3
      Seunghun Lee authored
      It would make more sense to pass char __user * instead of
      char * in callers of do_mount() and do getname() inside do_mount().
      Suggested-by: default avatarAl Viro <viro@ZenIV.linux.org.uk>
      Signed-off-by: default avatarSeunghun Lee <waydi1@gmail.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      5e6123f3
    • Tim Gardner's avatar
      fs: namespace: suppress 'may be used uninitialized' warnings · b8850d1f
      Tim Gardner authored
      The gcc version 4.9.1 compiler complains Even though it isn't possible for
      these variables to not get initialized before they are used.
      
      fs/namespace.c: In function ‘SyS_mount’:
      fs/namespace.c:2720:8: warning: ‘kernel_dev’ may be used uninitialized in this function [-Wmaybe-uninitialized]
        ret = do_mount(kernel_dev, kernel_dir->name, kernel_type, flags,
              ^
      fs/namespace.c:2699:8: note: ‘kernel_dev’ was declared here
        char *kernel_dev;
              ^
      fs/namespace.c:2720:8: warning: ‘kernel_type’ may be used uninitialized in this function [-Wmaybe-uninitialized]
        ret = do_mount(kernel_dev, kernel_dir->name, kernel_type, flags,
              ^
      fs/namespace.c:2697:8: note: ‘kernel_type’ was declared here
        char *kernel_type;
              ^
      
      Fix the warnings by simplifying copy_mount_string() as suggested by Al Viro.
      
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarTim Gardner <tim.gardner@canonical.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      b8850d1f
  14. 22 Apr, 2014 1 commit
    • Jeff Layton's avatar
      locks: rename file-private locks to "open file description locks" · 0d3f7a2d
      Jeff Layton authored
      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 <mtk.manpages@gmail.com>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Carlos O'Donell <carlos@redhat.com>
      Cc: Stefan Metzmacher <metze@samba.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Frank Filz <ffilzlnx@mindspring.com>
      Cc: Theodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      0d3f7a2d
  15. 31 Mar, 2014 1 commit
    • Jeff Layton's avatar
      locks: add new fcntl cmd values for handling file private locks · 5d50ffd7
      Jeff Layton authored
      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: default avatarJeff Layton <jlayton@redhat.com>
      5d50ffd7
  16. 06 Mar, 2014 2 commits
    • Heiko Carstens's avatar
      fs/compat: convert to COMPAT_SYSCALL_DEFINE with changing parameter types · 932602e2
      Heiko Carstens authored
      Some fs compat system calls have unsigned long parameters instead of
      compat_ulong_t.
      In order to allow the COMPAT_SYSCALL_DEFINE macro generate code that
      performs proper zero and sign extension convert all 64 bit parameters
      their corresponding 32 bit counterparts.
      
      compat_sys_io_getevents() is a bit different: the non-compat version
      has signed parameters for the "min_nr" and "nr" parameters while the
      compat version has unsigned parameters.
      So change this as well. For all practical purposes this shouldn't make
      any difference (doesn't fix a real bug).
      Also introduce a generic compat_aio_context_t type which can be used
      everywhere.
      The access_ok() check within compat_sys_io_getevents() got also removed
      since the non-compat sys_io_getevents() should be able to handle
      everything anyway.
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      932602e2
    • Heiko Carstens's avatar
      fs/compat: convert to COMPAT_SYSCALL_DEFINE · 625b1d7e
      Heiko Carstens authored
      Convert all compat system call functions where all parameter types
      have a size of four or less than four bytes, or are pointer types
      to COMPAT_SYSCALL_DEFINE.
      The implicit casts within COMPAT_SYSCALL_DEFINE will perform proper
      zero and sign extension to 64 bit of all parameters if needed.
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      625b1d7e
  17. 04 Mar, 2014 1 commit
    • Heiko Carstens's avatar
      compat: let architectures define __ARCH_WANT_COMPAT_SYS_GETDENTS64 · 0473c9b5
      Heiko Carstens authored
      For architecture dependent compat syscalls in common code an architecture
      must define something like __ARCH_WANT_<WHATEVER> 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: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      0473c9b5
  18. 02 Feb, 2014 1 commit
    • H. Peter Anvin's avatar
      compat: Get rid of (get|put)_compat_time(val|spec) · 81993e81
      H. Peter Anvin authored
      We have two APIs for compatiblity timespec/val, with confusingly
      similar names.  compat_(get|put)_time(val|spec) *do* handle the case
      where COMPAT_USE_64BIT_TIME is set, whereas
      (get|put)_compat_time(val|spec) do not.  This is an accident waiting
      to happen.
      
      Clean it up by favoring the full-service version; the limited version
      is replaced with double-underscore versions static to kernel/compat.c.
      
      A common pattern is to convert a struct timespec to kernel format in
      an allocation on the user stack.  Unfortunately it is open-coded in
      several places.  Since this allocation isn't actually needed if
      COMPAT_USE_64BIT_TIME is true (since user format == kernel format)
      encapsulate that whole pattern into the function
      compat_convert_timespec().  An equivalent function should be written
      for struct timeval if it is needed in the future.
      
      Finally, get rid of compat_(get|put)_timeval_convert(): each was only
      used once, and the latter was not even doing what the function said
      (no conversion actually was being done.)  Moving the conversion into
      compat_sys_settimeofday() itself makes the code much more similar to
      sys_settimeofday() itself.
      
      v3: Remove unused compat_convert_timeval().
      
      v2: Drop bogus "const" in the destination argument for
          compat_convert_time*().
      
      Cc: Mauro Carvalho Chehab <m.chehab@samsung.com>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Hans Verkuil <hans.verkuil@cisco.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Manfred Spraul <manfred@colorfullife.com>
      Cc: Mateusz Guzik <mguzik@redhat.com>
      Cc: Rafael Aquini <aquini@redhat.com>
      Cc: Davidlohr Bueso <davidlohr@hp.com>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Cc: Dan Carpenter <dan.carpenter@oracle.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Tested-by: default avatarH.J. Lu <hjl.tools@gmail.com>
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      81993e81
  19. 29 Jun, 2013 3 commits
  20. 08 May, 2013 1 commit
  21. 04 May, 2013 1 commit
  22. 09 Apr, 2013 2 commits
  23. 12 Mar, 2013 1 commit
    • Mathieu Desnoyers's avatar
      Fix: compat_rw_copy_check_uvector() misuse in aio, readv, writev, and security keys · 8aec0f5d
      Mathieu Desnoyers authored
      Looking at mm/process_vm_access.c:process_vm_rw() and comparing it to
      compat_process_vm_rw() shows that the compatibility code requires an
      explicit "access_ok()" check before calling
      compat_rw_copy_check_uvector(). The same difference seems to appear when
      we compare fs/read_write.c:do_readv_writev() to
      fs/compat.c:compat_do_readv_writev().
      
      This subtle difference between the compat and non-compat requirements
      should probably be debated, as it seems to be error-prone. In fact,
      there are two others sites that use this function in the Linux kernel,
      and they both seem to get it wrong:
      
      Now shifting our attention to fs/aio.c, we see that aio_setup_iocb()
      also ends up calling compat_rw_copy_check_uvector() through
      aio_setup_vectored_rw(). Unfortunately, the access_ok() check appears to
      be missing. Same situation for
      security/keys/compat.c:compat_keyctl_instantiate_key_iov().
      
      I propose that we add the access_ok() check directly into
      compat_rw_copy_check_uvector(), so callers don't have to worry about it,
      and it therefore makes the compat call code similar to its non-compat
      counterpart. Place the access_ok() check in the same location where
      copy_from_user() can trigger a -EFAULT error in the non-compat code, so
      the ABI behaviors are alike on both compat and non-compat.
      
      While we are here, fix compat_do_readv_writev() so it checks for
      compat_rw_copy_check_uvector() negative return values.
      
      And also, fix a memory leak in compat_keyctl_instantiate_key_iov() error
      handling.
      Acked-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Acked-by: default avatarAl Viro <viro@ZenIV.linux.org.uk>
      Signed-off-by: default avatarMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      8aec0f5d
  24. 04 Mar, 2013 2 commits