1. 04 4月, 2014 12 次提交
  2. 31 3月, 2014 5 次提交
  3. 29 3月, 2014 1 次提交
    • S
      ocfs2: check if cluster name exists before deref · d9060742
      Sasha Levin 提交于
      Commit c74a3bdd ("ocfs2: add clustername to cluster connection") is
      trying to strlcpy a string which was explicitly passed as NULL in the
      very same patch, triggering a NULL ptr deref.
      
        BUG: unable to handle kernel NULL pointer dereference at           (null)
        IP: strlcpy (lib/string.c:388 lib/string.c:151)
        CPU: 19 PID: 19426 Comm: trinity-c19 Tainted: G        W     3.14.0-rc7-next-20140325-sasha-00014-g9476368-dirty #274
        RIP:  strlcpy (lib/string.c:388 lib/string.c:151)
        Call Trace:
         ocfs2_cluster_connect (fs/ocfs2/stackglue.c:350)
         ocfs2_cluster_connect_agnostic (fs/ocfs2/stackglue.c:396)
         user_dlm_register (fs/ocfs2/dlmfs/userdlm.c:679)
         dlmfs_mkdir (fs/ocfs2/dlmfs/dlmfs.c:503)
         vfs_mkdir (fs/namei.c:3467)
         SyS_mkdirat (fs/namei.c:3488 fs/namei.c:3472)
         tracesys (arch/x86/kernel/entry_64.S:749)
      
      akpm: this patch probably disables the feature.  A temporary thing to
      avoid triviel oopses.
      Signed-off-by: NSasha Levin <sasha.levin@oracle.com>
      Cc: Goldwyn Rodrigues <rgoldwyn@suse.com>
      Cc: Mark Fasheh <mfasheh@suse.de>
      Cc: Joel Becker <jlbec@evilplan.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d9060742
  4. 28 3月, 2014 1 次提交
  5. 26 3月, 2014 3 次提交
  6. 24 3月, 2014 1 次提交
  7. 23 3月, 2014 4 次提交
    • A
      rcuwalk: recheck mount_lock after mountpoint crossing attempts · b37199e6
      Al Viro 提交于
      We can get false negative from __lookup_mnt() if an unrelated vfsmount
      gets moved.  In that case legitimize_mnt() is guaranteed to fail,
      and we will fall back to non-RCU walk... unless we end up running
      into a hard error on a filesystem object we wouldn't have reached
      if not for that false negative.  IOW, delaying that check until
      the end of pathname resolution is wrong - we should recheck right
      after we attempt to cross the mountpoint.  We don't need to recheck
      unless we see d_mountpoint() being true - in that case even if
      we have just raced with mount/umount, we can simply go on as if
      we'd come at the moment when the sucker wasn't a mountpoint; if we
      run into a hard error as the result, it was a legitimate outcome.
      __lookup_mnt() returning NULL is different in that respect, since
      it might've happened due to operation on completely unrelated
      mountpoint.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      b37199e6
    • A
      make prepend_name() work correctly when called with negative *buflen · e825196d
      Al Viro 提交于
      In all callchains leading to prepend_name(), the value left in *buflen
      is eventually discarded unused if prepend_name() has returned a negative.
      So we are free to do what prepend() does, and subtract from *buflen
      *before* checking for underflow (which turns into checking the sign
      of subtraction result, of course).
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      e825196d
    • E
      vfs: Don't let __fdget_pos() get FMODE_PATH files · 99aea681
      Eric Biggers 提交于
      Commit bd2a31d5 ("get rid of fget_light()") introduced the
      __fdget_pos() function, which returns the resulting file pointer and
      fdput flags combined in an 'unsigned long'.  However, it also changed the
      behavior to return files with FMODE_PATH set, which shouldn't happen
      because read(), write(), lseek(), etc. aren't allowed on such files.
      This commit restores the old behavior.
      
      This regression actually had no effect on read() and write() since
      FMODE_READ and FMODE_WRITE are not set on file descriptors opened with
      O_PATH, but it did cause lseek() on a file descriptor opened with O_PATH
      to fail with ESPIPE rather than EBADF.
      Signed-off-by: NEric Biggers <ebiggers3@gmail.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      99aea681
    • E
      vfs: atomic f_pos access in llseek() · d7a15f8d
      Eric Biggers 提交于
      Commit 9c225f26 ("vfs: atomic f_pos accesses as per POSIX") changed
      several system calls to use fdget_pos() instead of fdget(), but missed
      sys_llseek().  Fix it.
      Signed-off-by: NEric Biggers <ebiggers3@gmail.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      d7a15f8d
  8. 13 3月, 2014 1 次提交
    • F
      cputime: Default implementation of nsecs -> cputime conversion · bfc3f028
      Frederic Weisbecker 提交于
      The architectures that override cputime_t (s390, ppc) don't provide
      any version of nsecs_to_cputime(). Indeed this cputime_t implementation
      by backend only happens when CONFIG_VIRT_CPU_ACCOUNTING_NATIVE=y under
      which the core code doesn't make any use of nsecs_to_cputime().
      
      At least for now.
      
      We are going to make a broader use of it so lets provide a default
      version with a per usecs granularity. It should be good enough for most
      usecases.
      
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Marcelo Tosatti <mtosatti@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Acked-by: NRik van Riel <riel@redhat.com>
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      bfc3f028
  9. 12 3月, 2014 1 次提交
    • G
      of: remove /proc/device-tree · 8357041a
      Grant Likely 提交于
      The same data is now available in sysfs, so we can remove the code
      that exports it in /proc and replace it with a symlink to the sysfs
      version.
      
      Tested on versatile qemu model and mpc5200 eval board. More testing
      would be appreciated.
      
      v5: Fixed up conflicts with mainline changes
      Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
      Cc: Rob Herring <rob.herring@calxeda.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Nathan Fontenot <nfont@linux.vnet.ibm.com>
      Cc: Pantelis Antoniou <panto@antoniou-consulting.com>
      8357041a
  10. 11 3月, 2014 2 次提交
  11. 10 3月, 2014 3 次提交
    • A
      get rid of fget_light() · bd2a31d5
      Al Viro 提交于
      instead of returning the flags by reference, we can just have the
      low-level primitive return those in lower bits of unsigned long,
      with struct file * derived from the rest.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      bd2a31d5
    • L
      vfs: atomic f_pos accesses as per POSIX · 9c225f26
      Linus Torvalds 提交于
      Our write() system call has always been atomic in the sense that you get
      the expected thread-safe contiguous write, but we haven't actually
      guaranteed that concurrent writes are serialized wrt f_pos accesses, so
      threads (or processes) that share a file descriptor and use "write()"
      concurrently would quite likely overwrite each others data.
      
      This violates POSIX.1-2008/SUSv4 Section XSI 2.9.7 that says:
      
       "2.9.7 Thread Interactions with Regular File Operations
      
        All of the following functions shall be atomic with respect to each
        other in the effects specified in POSIX.1-2008 when they operate on
        regular files or symbolic links: [...]"
      
      and one of the effects is the file position update.
      
      This unprotected file position behavior is not new behavior, and nobody
      has ever cared.  Until now.  Yongzhi Pan reported unexpected behavior to
      Michael Kerrisk that was due to this.
      
      This resolves the issue with a f_pos-specific lock that is taken by
      read/write/lseek on file descriptors that may be shared across threads
      or processes.
      Reported-by: NYongzhi Pan <panyongzhi@gmail.com>
      Reported-by: NMichael Kerrisk <mtk.manpages@gmail.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      9c225f26
    • A
      ocfs2 syncs the wrong range... · 1b56e989
      Al Viro 提交于
      Cc: stable@vger.kernel.org
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      1b56e989
  12. 09 3月, 2014 2 次提交
    • T
      kernfs: cache atomic_write_len in kernfs_open_file · b7ce40cf
      Tejun Heo 提交于
      While implementing atomic_write_len, 4d3773c4 ("kernfs: implement
      kernfs_ops->atomic_write_len") moved data copy from userland inside
      kernfs_get_active() and kernfs_open_file->mutex so that
      kernfs_ops->atomic_write_len can be accessed before copying buffer
      from userland; unfortunately, this could lead to locking order
      inversion involving mmap_sem if copy_from_user() takes a page fault.
      
        ======================================================
        [ INFO: possible circular locking dependency detected ]
        3.14.0-rc4-next-20140228-sasha-00011-g4077c67-dirty #26 Tainted: G        W
        -------------------------------------------------------
        trinity-c236/10658 is trying to acquire lock:
         (&of->mutex#2){+.+.+.}, at: [<fs/kernfs/file.c:487>] kernfs_fop_mmap+0x54/0x120
      
        but task is already holding lock:
         (&mm->mmap_sem){++++++}, at: [<mm/util.c:397>] vm_mmap_pgoff+0x6e/0xe0
      
        which lock already depends on the new lock.
      
        the existing dependency chain (in reverse order) is:
      
       -> #1 (&mm->mmap_sem){++++++}:
      	 [<kernel/locking/lockdep.c:1945 kernel/locking/lockdep.c:2131>] validate_chain+0x6c5/0x7b0
      	 [<kernel/locking/lockdep.c:3182>] __lock_acquire+0x4cd/0x5a0
      	 [<arch/x86/include/asm/current.h:14 kernel/locking/lockdep.c:3602>] lock_acquire+0x182/0x1d0
      	 [<mm/memory.c:4188>] might_fault+0x7e/0xb0
      	 [<arch/x86/include/asm/uaccess.h:713 fs/kernfs/file.c:291>] kernfs_fop_write+0xd8/0x190
      	 [<fs/read_write.c:473>] vfs_write+0xe3/0x1d0
      	 [<fs/read_write.c:523 fs/read_write.c:515>] SyS_write+0x5d/0xa0
      	 [<arch/x86/kernel/entry_64.S:749>] tracesys+0xdd/0xe2
      
       -> #0 (&of->mutex#2){+.+.+.}:
      	 [<kernel/locking/lockdep.c:1840>] check_prev_add+0x13f/0x560
      	 [<kernel/locking/lockdep.c:1945 kernel/locking/lockdep.c:2131>] validate_chain+0x6c5/0x7b0
      	 [<kernel/locking/lockdep.c:3182>] __lock_acquire+0x4cd/0x5a0
      	 [<arch/x86/include/asm/current.h:14 kernel/locking/lockdep.c:3602>] lock_acquire+0x182/0x1d0
      	 [<kernel/locking/mutex.c:470 kernel/locking/mutex.c:571>] mutex_lock_nested+0x6a/0x510
      	 [<fs/kernfs/file.c:487>] kernfs_fop_mmap+0x54/0x120
      	 [<mm/mmap.c:1573>] mmap_region+0x310/0x5c0
      	 [<mm/mmap.c:1365>] do_mmap_pgoff+0x385/0x430
      	 [<mm/util.c:399>] vm_mmap_pgoff+0x8f/0xe0
      	 [<mm/mmap.c:1416 mm/mmap.c:1374>] SyS_mmap_pgoff+0x1b0/0x210
      	 [<arch/x86/kernel/sys_x86_64.c:72>] SyS_mmap+0x1d/0x20
      	 [<arch/x86/kernel/entry_64.S:749>] tracesys+0xdd/0xe2
      
        other info that might help us debug this:
      
         Possible unsafe locking scenario:
      
      	 CPU0                    CPU1
      	 ----                    ----
          lock(&mm->mmap_sem);
      				 lock(&of->mutex#2);
      				 lock(&mm->mmap_sem);
          lock(&of->mutex#2);
      
         *** DEADLOCK ***
      
        1 lock held by trinity-c236/10658:
         #0:  (&mm->mmap_sem){++++++}, at: [<mm/util.c:397>] vm_mmap_pgoff+0x6e/0xe0
      
        stack backtrace:
        CPU: 2 PID: 10658 Comm: trinity-c236 Tainted: G        W 3.14.0-rc4-next-20140228-sasha-00011-g4077c67-dirty #26
         0000000000000000 ffff88011911fa48 ffffffff8438e945 0000000000000000
         0000000000000000 ffff88011911fa98 ffffffff811a0109 ffff88011911fab8
         ffff88011911fab8 ffff88011911fa98 ffff880119128cc0 ffff880119128cf8
        Call Trace:
         [<lib/dump_stack.c:52>] dump_stack+0x52/0x7f
         [<kernel/locking/lockdep.c:1213>] print_circular_bug+0x129/0x160
         [<kernel/locking/lockdep.c:1840>] check_prev_add+0x13f/0x560
         [<include/linux/spinlock.h:343 mm/slub.c:1933>] ? deactivate_slab+0x511/0x550
         [<kernel/locking/lockdep.c:1945 kernel/locking/lockdep.c:2131>] validate_chain+0x6c5/0x7b0
         [<kernel/locking/lockdep.c:3182>] __lock_acquire+0x4cd/0x5a0
         [<mm/mmap.c:1552>] ? mmap_region+0x24a/0x5c0
         [<arch/x86/include/asm/current.h:14 kernel/locking/lockdep.c:3602>] lock_acquire+0x182/0x1d0
         [<fs/kernfs/file.c:487>] ? kernfs_fop_mmap+0x54/0x120
         [<kernel/locking/mutex.c:470 kernel/locking/mutex.c:571>] mutex_lock_nested+0x6a/0x510
         [<fs/kernfs/file.c:487>] ? kernfs_fop_mmap+0x54/0x120
         [<kernel/sched/core.c:2477>] ? get_parent_ip+0x11/0x50
         [<fs/kernfs/file.c:487>] ? kernfs_fop_mmap+0x54/0x120
         [<fs/kernfs/file.c:487>] kernfs_fop_mmap+0x54/0x120
         [<mm/mmap.c:1573>] mmap_region+0x310/0x5c0
         [<mm/mmap.c:1365>] do_mmap_pgoff+0x385/0x430
         [<mm/util.c:397>] ? vm_mmap_pgoff+0x6e/0xe0
         [<mm/util.c:399>] vm_mmap_pgoff+0x8f/0xe0
         [<kernel/rcu/update.c:97>] ? __rcu_read_unlock+0x44/0xb0
         [<fs/file.c:641>] ? dup_fd+0x3c0/0x3c0
         [<mm/mmap.c:1416 mm/mmap.c:1374>] SyS_mmap_pgoff+0x1b0/0x210
         [<arch/x86/kernel/sys_x86_64.c:72>] SyS_mmap+0x1d/0x20
         [<arch/x86/kernel/entry_64.S:749>] tracesys+0xdd/0xe2
      
      Fix it by caching atomic_write_len in kernfs_open_file during open so
      that it can be determined without accessing kernfs_ops in
      kernfs_fop_write().  This restores the structure of kernfs_fop_write()
      before 4d3773c4 with updated @len determination logic.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Reported-by: NSasha Levin <sasha.levin@oracle.com>
      References: http://lkml.kernel.org/g/53113485.2090407@oracle.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b7ce40cf
    • R
      kernfs: fix off by one error. · 88391d49
      Richard Cochran 提交于
      The hash values 0 and 1 are reserved for magic directory entries, but
      the code only prevents names hashing to 0. This patch fixes the test
      to also prevent hash value 1.
      Signed-off-by: NRichard Cochran <richardcochran@gmail.com>
      Cc: <stable@vger.kernel.org>
      Reviewed-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      88391d49
  13. 07 3月, 2014 1 次提交
    • T
      afs: don't use PREPARE_WORK · 05949945
      Tejun Heo 提交于
      PREPARE_[DELAYED_]WORK() are being phased out.  They have few users
      and a nasty surprise in terms of reentrancy guarantee as workqueue
      considers work items to be different if they don't have the same work
      function.
      
      afs_call->async_work is multiplexed with multiple work functions.
      Introduce afs_async_workfn() which invokes afs_call->async_workfn and
      always use it as the work function and update the users to set the
      ->async_workfn field instead of overriding the work function using
      PREPARE_WORK().
      
      It would probably be best to route this with other related updates
      through the workqueue tree.
      
      Compile tested.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: David Howells <dhowells@redhat.com>
      Cc: linux-afs@lists.infradead.org
      05949945
  14. 06 3月, 2014 3 次提交
    • H
      fs/compat: convert to COMPAT_SYSCALL_DEFINE with changing parameter types · 932602e2
      Heiko Carstens 提交于
      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: NHeiko Carstens <heiko.carstens@de.ibm.com>
      932602e2
    • H
      fs/compat: convert to COMPAT_SYSCALL_DEFINE · 625b1d7e
      Heiko Carstens 提交于
      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: NHeiko Carstens <heiko.carstens@de.ibm.com>
      625b1d7e
    • H
      fs/compat: optional preadv64/pwrite64 compat system calls · 378a10f3
      Heiko Carstens 提交于
      The preadv64/pwrite64 have been implemented for the x32 ABI, in order
      to allow passing 64 bit arguments from user space without splitting
      them into two 32 bit parameters, like it would be necessary for usual
      compat tasks.
      Howevert these two system calls are only being used for the x32 ABI,
      so add __ARCH_WANT_COMPAT defines for these two compat syscalls and
      make these two only visible for x86.
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      378a10f3