1. 01 Jun, 2012 40 commits
    • Al Viro's avatar
      new helper: signal_delivered() · efee984c
      Al Viro authored
      Does block_sigmask() + tracehook_signal_handler();  called when
      sigframe has been successfully built.  All architectures converted
      to it; block_sigmask() itself is gone now (merged into this one).
      
      I'm still not too happy with the signature, but that's a separate
      story (IMO we need a structure that would contain signal number +
      siginfo + k_sigaction, so that get_signal_to_deliver() would fill one,
      signal_delivered(), handle_signal() and probably setup...frame() -
      take one).
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      efee984c
    • Al Viro's avatar
      powerpc: get rid of restore_sigmask() · 17440f17
      Al Viro authored
      ... it's just a call of set_current_blocked() now
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      17440f17
    • Al Viro's avatar
      most of set_current_blocked() callers want SIGKILL/SIGSTOP removed from set · 77097ae5
      Al Viro authored
      Only 3 out of 63 do not.  Renamed the current variant to __set_current_blocked(),
      added set_current_blocked() that will exclude unblockable signals, switched
      open-coded instances to it.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      77097ae5
    • Al Viro's avatar
    • Al Viro's avatar
    • Al Viro's avatar
      don't call try_to_freeze() from do_signal() · bf343dfd
      Al Viro authored
      get_signal_to_deliver() will handle it itself
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      bf343dfd
    • Al Viro's avatar
      a610d6e6
    • Al Viro's avatar
      sh64: failure to build sigframe != signal without handler · 5754f412
      Al Viro authored
      it's actually "send me SIGSEGV"...
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      5754f412
    • Al Viro's avatar
      openrisc: tracehook_signal_handler() is supposed to be called on success · 39974d08
      Al Viro authored
      ... not if sigframe couldn't have been built.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      39974d08
    • Al Viro's avatar
      new helper: sigmask_to_save() · b7f9a11a
      Al Viro authored
      replace boilerplate "should we use ->saved_sigmask or ->blocked?"
      with calls of obvious inlined helper...
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      b7f9a11a
    • Al Viro's avatar
      new helper: restore_saved_sigmask() · 51a7b448
      Al Viro authored
      first fruits of ..._restore_sigmask() helpers: now we can take
      boilerplate "signal didn't have a handler, clear RESTORE_SIGMASK
      and restore the blocked mask from ->saved_mask" into a common
      helper.  Open-coded instances switched...
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      51a7b448
    • Al Viro's avatar
      new helpers: {clear,test,test_and_clear}_restore_sigmask() · 4ebefe3e
      Al Viro authored
      helpers parallel to set_restore_sigmask(), used in the next commits
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      4ebefe3e
    • Al Viro's avatar
      HAVE_RESTORE_SIGMASK is defined on all architectures now · 754421c8
      Al Viro authored
      Everyone either defines it in arch thread_info.h or has TIF_RESTORE_SIGMASK
      and picks default set_restore_sigmask() in linux/thread_info.h.  Kill the
      ifdefs, slap #error in linux/thread_info.h to catch breakage when new ones
      get merged.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      754421c8
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/signal · fb21affa
      Linus Torvalds authored
      Pull second pile of signal handling patches from Al Viro:
       "This one is just task_work_add() series + remaining prereqs for it.
      
        There probably will be another pull request from that tree this
        cycle - at least for helpers, to get them out of the way for per-arch
        fixes remaining in the tree."
      
      Fix trivial conflict in kernel/irq/manage.c: the merge of Andrew's pile
      had brought in commit 97fd75b7 ("kernel/irq/manage.c: use the
      pr_foo() infrastructure to prefix printks") which changed one of the
      pr_err() calls that this merge moves around.
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/signal:
        keys: kill task_struct->replacement_session_keyring
        keys: kill the dummy key_replace_session_keyring()
        keys: change keyctl_session_to_parent() to use task_work_add()
        genirq: reimplement exit_irq_thread() hook via task_work_add()
        task_work_add: generic process-context callbacks
        avr32: missed _TIF_NOTIFY_RESUME on one of do_notify_resume callers
        parisc: need to check NOTIFY_RESUME when exiting from syscall
        move key_repace_session_keyring() into tracehook_notify_resume()
        TIF_NOTIFY_RESUME is defined on all targets now
      fb21affa
    • Linus Torvalds's avatar
      Merge branch 'for-3.5-take-2' of git://linux-nfs.org/~bfields/linux · a00b6151
      Linus Torvalds authored
      Pull nfsd update from Bruce Fields.
      
      * 'for-3.5-take-2' of git://linux-nfs.org/~bfields/linux: (23 commits)
        nfsd: trivial: use SEEK_SET instead of 0 in vfs_llseek
        SUNRPC: split upcall function to extract reusable parts
        nfsd: allocate id-to-name and name-to-id caches in per-net operations.
        nfsd: make name-to-id cache allocated per network namespace context
        nfsd: make id-to-name cache allocated per network namespace context
        nfsd: pass network context to idmap init/exit functions
        nfsd: allocate export and expkey caches in per-net operations.
        nfsd: make expkey cache allocated per network namespace context
        nfsd: make export cache allocated per network namespace context
        nfsd: pass pointer to export cache down to stack wherever possible.
        nfsd: pass network context to export caches init/shutdown routines
        Lockd: pass network namespace to creation and destruction routines
        NFSd: remove hard-coded dereferences to name-to-id and id-to-name caches
        nfsd: pass pointer to expkey cache down to stack wherever possible.
        nfsd: use hash table from cache detail in nfsd export seq ops
        nfsd: pass svc_export_cache pointer as private data to "exports" seq file ops
        nfsd: use exp_put() for svc_export_cache put
        nfsd: use cache detail pointer from svc_export structure on cache put
        nfsd: add link to owner cache detail to svc_export structure
        nfsd: use passed cache_detail pointer expkey_parse()
        ...
      a00b6151
    • Linus Torvalds's avatar
      Merge branch 'akpm' (Andrew's patch-bomb) · 08615d7d
      Linus Torvalds authored
      Merge misc patches from Andrew Morton:
      
       - the "misc" tree - stuff from all over the map
      
       - checkpatch updates
      
       - fatfs
      
       - kmod changes
      
       - procfs
      
       - cpumask
      
       - UML
      
       - kexec
      
       - mqueue
      
       - rapidio
      
       - pidns
      
       - some checkpoint-restore feature work.  Reluctantly.  Most of it
         delayed a release.  I'm still rather worried that we don't have a
         clear roadmap to completion for this work.
      
      * emailed from Andrew Morton <akpm@linux-foundation.org>: (78 patches)
        kconfig: update compression algorithm info
        c/r: prctl: add ability to set new mm_struct::exe_file
        c/r: prctl: extend PR_SET_MM to set up more mm_struct entries
        c/r: procfs: add arg_start/end, env_start/end and exit_code members to /proc/$pid/stat
        syscalls, x86: add __NR_kcmp syscall
        fs, proc: introduce /proc/<pid>/task/<tid>/children entry
        sysctl: make kernel.ns_last_pid control dependent on CHECKPOINT_RESTORE
        aio/vfs: cleanup of rw_copy_check_uvector() and compat_rw_copy_check_uvector()
        eventfd: change int to __u64 in eventfd_signal()
        fs/nls: add Apple NLS
        pidns: make killed children autoreap
        pidns: use task_active_pid_ns in do_notify_parent
        rapidio/tsi721: add DMA engine support
        rapidio: add DMA engine support for RIO data transfers
        ipc/mqueue: add rbtree node caching support
        tools/selftests: add mq_perf_tests
        ipc/mqueue: strengthen checks on mqueue creation
        ipc/mqueue: correct mq_attr_ok test
        ipc/mqueue: improve performance of send/recv
        selftests: add mq_open_tests
        ...
      08615d7d
    • Linus Torvalds's avatar
      Merge branch 'drm-prime-vmap' of git://people.freedesktop.org/~airlied/linux · 9fdadb2c
      Linus Torvalds authored
      Pull drm prime mmap/vmap code from Dave Airlie:
       "As mentioned previously these are the extra bits of drm that relied on
        the dma-buf pull to work, the first three just stub out the mmap
        interface, and the next set provide vmap export to i915/radeon/nouveau
        and vmap import to udl."
      
      * 'drm-prime-vmap' of git://people.freedesktop.org/~airlied/linux:
        radeon: add radeon prime vmap support.
        nouveau: add vmap support to nouveau prime support
        udl: support vmapping imported dma-bufs
        i915: add dma-buf vmap support for exporting vmapped buffer
        radeon: add stub dma-buf mmap functionality
        nouveau: add stub dma-buf mmap functionality.
        i915: add stub dma-buf mmap callback.
      9fdadb2c
    • Randy Dunlap's avatar
      kconfig: update compression algorithm info · 0a4dd35c
      Randy Dunlap authored
      There have been new compression algorithms added without updating nearby
      relevant descriptive text that refers to (a) the number of compression
      algorithms and (b) the most recent one.  Fix these inconsistencies.
      Signed-off-by: default avatarRandy Dunlap <rdunlap@xenotime.net>
      Reported-by: <qasdfgtyuiop@gmail.com>
      Cc: Lasse Collin <lasse.collin@tukaani.org>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Markus Trippelsdorf <markus@trippelsdorf.de>
      Cc: Alain Knaff <alain@knaff.lu>
      Cc: Albin Tonnerre <albin.tonnerre@free-electrons.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      0a4dd35c
    • Cyrill Gorcunov's avatar
      c/r: prctl: add ability to set new mm_struct::exe_file · b32dfe37
      Cyrill Gorcunov authored
      When we do restore we would like to have a way to setup a former
      mm_struct::exe_file so that /proc/pid/exe would point to the original
      executable file a process had at checkpoint time.
      
      For this the PR_SET_MM_EXE_FILE code is introduced.  This option takes a
      file descriptor which will be set as a source for new /proc/$pid/exe
      symlink.
      
      Note it allows to change /proc/$pid/exe if there are no VM_EXECUTABLE
      vmas present for current process, simply because this feature is a special
      to C/R and mm::num_exe_file_vmas become meaningless after that.
      
      To minimize the amount of transition the /proc/pid/exe symlink might have,
      this feature is implemented in one-shot manner.  Thus once changed the
      symlink can't be changed again.  This should help sysadmins to monitor the
      symlinks over all process running in a system.
      
      In particular one could make a snapshot of processes and ring alarm if
      there unexpected changes of /proc/pid/exe's in a system.
      
      Note -- this feature is available iif CONFIG_CHECKPOINT_RESTORE is set and
      the caller must have CAP_SYS_RESOURCE capability granted, otherwise the
      request to change symlink will be rejected.
      Signed-off-by: default avatarCyrill Gorcunov <gorcunov@openvz.org>
      Reviewed-by: default avatarOleg Nesterov <oleg@redhat.com>
      Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Cc: Pavel Emelyanov <xemul@parallels.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Matt Helsley <matthltc@us.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b32dfe37
    • Cyrill Gorcunov's avatar
      c/r: prctl: extend PR_SET_MM to set up more mm_struct entries · fe8c7f5c
      Cyrill Gorcunov authored
      During checkpoint we dump whole process memory to a file and the dump
      includes process stack memory.  But among stack data itself, the stack
      carries additional parameters such as command line arguments, environment
      data and auxiliary vector.
      
      So when we do restore procedure and once we've restored stack data itself
      we need to setup mm_struct::arg_start/end, env_start/end, so restored
      process would be able to find command line arguments and environment data
      it had at checkpoint time.  The same applies to auxiliary vector.
      
      For this reason additional PR_SET_MM_(ARG_START | ARG_END | ENV_START |
      ENV_END | AUXV) codes are introduced.
      Signed-off-by: default avatarCyrill Gorcunov <gorcunov@openvz.org>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Andrew Vagin <avagin@openvz.org>
      Cc: Serge Hallyn <serge.hallyn@canonical.com>
      Cc: Pavel Emelyanov <xemul@parallels.com>
      Cc: Vasiliy Kulikov <segoon@openwall.com>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Michael Kerrisk <mtk.manpages@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      fe8c7f5c
    • Cyrill Gorcunov's avatar
      c/r: procfs: add arg_start/end, env_start/end and exit_code members to /proc/$pid/stat · 5b172087
      Cyrill Gorcunov authored
      We would like to have an ability to restore command line arguments and
      program environment pointers but first we need to obtain them somehow.
      Thus we put these values into /proc/$pid/stat.  The exit_code is needed to
      restore zombie tasks.
      Signed-off-by: default avatarCyrill Gorcunov <gorcunov@openvz.org>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Pavel Emelyanov <xemul@parallels.com>
      Cc: Serge Hallyn <serge.hallyn@canonical.com>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Andrew Vagin <avagin@openvz.org>
      Cc: Vasiliy Kulikov <segoon@openwall.com>
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      5b172087
    • Cyrill Gorcunov's avatar
      syscalls, x86: add __NR_kcmp syscall · d97b46a6
      Cyrill Gorcunov authored
      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: default avatarCyrill Gorcunov <gorcunov@openvz.org>
      Acked-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Pavel Emelyanov <xemul@parallels.com>
      Cc: Andrey Vagin <avagin@openvz.org>
      Cc: KOSAKI Motohiro <kosaki.motohiro@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Glauber Costa <glommer@parallels.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Matt Helsley <matthltc@us.ibm.com>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: Vasiliy Kulikov <segoon@openwall.com>
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Cc: Valdis.Kletnieks@vt.edu
      Cc: Michal Marek <mmarek@suse.cz>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      d97b46a6
    • Cyrill Gorcunov's avatar
      fs, proc: introduce /proc/<pid>/task/<tid>/children entry · 81841161
      Cyrill Gorcunov authored
      When we do checkpoint of a task we need to know the list of children the
      task, has but there is no easy and fast way to generate reverse
      parent->children chain from arbitrary <pid> (while a parent pid is
      provided in "PPid" field of /proc/<pid>/status).
      
      So instead of walking over all pids in the system (creating one big
      process tree in memory, just to figure out which children a task has) --
      we add explicit /proc/<pid>/task/<tid>/children entry, because the kernel
      already has this kind of information but it is not yet exported.
      
      This is a first level children, not the whole process tree.
      Signed-off-by: default avatarCyrill Gorcunov <gorcunov@openvz.org>
      Reviewed-by: default avatarOleg Nesterov <oleg@redhat.com>
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Pavel Emelyanov <xemul@parallels.com>
      Cc: Serge Hallyn <serge.hallyn@canonical.com>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      81841161
    • Cyrill Gorcunov's avatar
      sysctl: make kernel.ns_last_pid control dependent on CHECKPOINT_RESTORE · 98ed57ee
      Cyrill Gorcunov authored
      For those who doesn't need C/R functionality there is no need to control
      last pid, ie the pid for the next fork() call.
      Signed-off-by: default avatarCyrill Gorcunov <gorcunov@openvz.org>
      Cc: Pavel Emelyanov <xemul@parallels.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      98ed57ee
    • Christopher Yeoh's avatar
      aio/vfs: cleanup of rw_copy_check_uvector() and compat_rw_copy_check_uvector() · ac34ebb3
      Christopher Yeoh authored
      A cleanup of rw_copy_check_uvector and compat_rw_copy_check_uvector after
      changes made to support CMA in an earlier patch.
      
      Rather than having an additional check_access parameter to these
      functions, the first paramater type is overloaded to allow the caller to
      specify CHECK_IOVEC_ONLY which means check that the contents of the iovec
      are valid, but do not check the memory that they point to.  This is used
      by process_vm_readv/writev where we need to validate that a iovec passed
      to the syscall is valid but do not want to check the memory that it points
      to at this point because it refers to an address space in another process.
      Signed-off-by: default avatarChris Yeoh <yeohc@au1.ibm.com>
      Reviewed-by: default avatarOleg Nesterov <oleg@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      ac34ebb3
    • Sha Zhengju's avatar
      eventfd: change int to __u64 in eventfd_signal() · ee62c6b2
      Sha Zhengju authored
      eventfd_ctx->count is an __u64 counter which is allowed to reach
      ULLONG_MAX.  eventfd_write() adds a __u64 value to "count", but the kernel
      side eventfd_signal() only adds an int value to it.  Make them consistent.
      
      [akpm@linux-foundation.org: update interface documentation]
      Signed-off-by: default avatarSha Zhengju <handai.szj@taobao.com>
      Cc: Davide Libenzi <davidel@xmailserver.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      ee62c6b2
    • Vladimir Serbinenko's avatar
      fs/nls: add Apple NLS · 71ca97da
      Vladimir Serbinenko authored
      HFS has support for NLS.  However the relevant NLS tables are missing.
      Here they are automatically transformed from the tables at unicode.org.
      Codepages requiring special handling like CJK, RTL or Brahmic ones are not
      included in this patch.
      
      [akpm@linux-foundation.org: add unicode.org copyright and permission notices]
      Signed-off-by: default avatarVladimir Serbinenko <phcoder@gmail.com>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
      Cc: Clemens Ladisch <clemens@ladisch.de>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Christoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      71ca97da
    • Eric W. Biederman's avatar
      pidns: make killed children autoreap · 00c10bc1
      Eric W. Biederman authored
      Force SIGCHLD handling to SIG_IGN so that signals are not generated and so
      that the children autoreap.  This increases the parallelize and in general
      the speed of network namespace shutdown.
      
      Note self reaping childrean can exist past zap_pid_ns_processess but they
      will all be reaped before we allow the pid namespace init task with pid ==
      1 to be reaped.
      
      [akpm@linux-foundation.org: checkpatch fixes]
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Pavel Emelyanov <xemul@parallels.com>
      Cc: Cyrill Gorcunov <gorcunov@openvz.org>
      Cc: Louis Rilling <louis.rilling@kerlabs.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      00c10bc1
    • Eric W. Biederman's avatar
      pidns: use task_active_pid_ns in do_notify_parent · 32084504
      Eric W. Biederman authored
      Using task_active_pid_ns is more robust because it works even after we
      have called exit_namespaces.  This change allows us to have parent
      processes that are zombies.  Normally a zombie parent processes is crazy
      and the last thing you would want to have but in the case of not letting
      the init process of a pid namespace be reaped until all of it's children
      are dead and reaped a zombie parent process is exactly what we want.
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Pavel Emelyanov <xemul@parallels.com>
      Cc: Cyrill Gorcunov <gorcunov@openvz.org>
      Cc: Louis Rilling <louis.rilling@kerlabs.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      32084504
    • Alexandre Bounine's avatar
      rapidio/tsi721: add DMA engine support · 9eaa3d9b
      Alexandre Bounine authored
      Adds support for DMA Engine API into Tsi721 mport driver.
      
      Includes following changes for Tsi721 driver:
      - Modifies BDMA register offset definitions to support per-channel handling
      - Separates BDMA channel reserved for RIO Maintenance requests
      - Adds DMA Engine callback routines
      Signed-off-by: default avatarAlexandre Bounine <alexandre.bounine@idt.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Vinod Koul <vinod.koul@intel.com>
      Cc: Li Yang <leoli@freescale.com>
      Cc: Matt Porter <mporter@kernel.crashing.org>
      Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      9eaa3d9b
    • Alexandre Bounine's avatar
      rapidio: add DMA engine support for RIO data transfers · e42d98eb
      Alexandre Bounine authored
      Adds DMA Engine framework support into RapidIO subsystem.
      
      Uses DMA Engine DMA_SLAVE interface to generate data transfers to/from
      remote RapidIO target devices.
      
      Introduces RapidIO-specific wrapper for prep_slave_sg() interface with an
      extra parameter to pass target specific information.
      
      Uses scatterlist to describe local data buffer.  Address flat data buffer
      on a remote side.
      Signed-off-by: default avatarAlexandre Bounine <alexandre.bounine@idt.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Acked-by: default avatarVinod Koul <vinod.koul@linux.intel.com>
      Cc: Li Yang <leoli@freescale.com>
      Cc: Matt Porter <mporter@kernel.crashing.org>
      Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      e42d98eb
    • Doug Ledford's avatar
      ipc/mqueue: add rbtree node caching support · ce2d52cc
      Doug Ledford authored
      When I wrote the first patch that added the rbtree support for message
      queue insertion, it sped up the case where the queue was very full
      drastically from the original code.  It, however, slowed down the case
      where the queue was empty (not drastically though).
      
      This patch caches the last freed rbtree node struct so we can quickly
      reuse it when we get a new message.  This is the common path for any queue
      that very frequently goes from 0 to 1 then back to 0 messages in queue.
      
      Andrew Morton didn't like that we were doing a GFP_ATOMIC allocation in
      msg_insert, so this patch attempts to speculatively allocate a new node
      struct outside of the spin lock when we know we need it, but will still
      fall back to a GFP_ATOMIC allocation if it has to.
      
      Once I added the caching, the necessary various ret = ; spin_unlock
      gyrations in mq_timedsend were getting pretty ugly, so this also slightly
      refactors that function to streamline the flow of the code and the
      function exit.
      
      Finally, while working on getting performance back I made sure that all of
      the node structs were always fully initialized when they were first used,
      rendering the use of kzalloc unnecessary and a waste of CPU cycles.
      
      The net result of all of this is:
      
      1) We will avoid a GFP_ATOMIC allocation when possible, but fall back
         on it when necessary.
      
      2) We will speculatively allocate a node struct using GFP_KERNEL if our
         cache is empty (and save the struct to our cache if it's still empty
         after we have obtained the spin lock).
      
      3) The performance of the common queue empty case has significantly
         improved and is now much more in line with the older performance for
         this case.
      
      The performance changes are:
      
                  Old mqueue      new mqueue      new mqueue + caching
      queue empty
      send/recv   305/288ns       349/318ns       310/322ns
      
      I don't think we'll ever be able to get the recv performance back, but
      that's because the old recv performance was a direct result and
      consequence of the old methods abysmal send performance.  The recv path
      simply must do more so that the send path does not incur such a penalty
      under higher queue depths.
      
      As it turns out, the new caching code also sped up the various queue full
      cases relative to my last patch.  That could be because of the difference
      between the syscall path in 3.3.4-rc5 and 3.3.4-rc6, or because of the
      change in code flow in the mq_timedsend routine.  Regardless, I'll take
      it.  It wasn't huge, and I *would* say it was within the margin for error,
      but after many repeated runs what I'm seeing is that the old numbers trend
      slightly higher (about 10 to 20ns depending on which test is the one
      running).
      
      [akpm@linux-foundation.org: checkpatch fixes]
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Manfred Spraul <manfred@colorfullife.com>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      ce2d52cc
    • Doug Ledford's avatar
      tools/selftests: add mq_perf_tests · 7820b071
      Doug Ledford authored
      Add the mq_perf_tests tool I used when creating my mq performance patch.
      Also add a local .gitignore to keep the binaries from showing up in git
      status output.
      
      [akpm@linux-foundation.org: checkpatch fixes]
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Cc: Manfred Spraul <manfred@colorfullife.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Acked-by: default avatarKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      7820b071
    • Doug Ledford's avatar
      ipc/mqueue: strengthen checks on mqueue creation · 113289cc
      Doug Ledford authored
      We already check the mq attr struct if it's passed in, but now that the
      admin can set system wide defaults separate from maximums, it's actually
      possible to set the defaults to something that would overflow.  So, if
      there is no attr struct passed in to the open call, check the default
      values.
      
      While we are at it, simplify mq_attr_ok() by making it return 0 or an
      error condition, so that way if we add more tests to it later, we have the
      option of what error should be returned instead of the calling location
      having to pick a possibly inaccurate error code.
      
      [akpm@linux-foundation.org: s/ENOMEM/EOVERFLOW/]
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Cc: Manfred Spraul <manfred@colorfullife.com>
      Acked-by: default avatarKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      113289cc
    • Doug Ledford's avatar
      ipc/mqueue: correct mq_attr_ok test · 2c12ea49
      Doug Ledford authored
      While working on the other parts of the mqueue stuff, I noticed that the
      calculation for overflow in mq_attr_ok didn't actually match reality (this
      is especially true since my last patch which changed how we account memory
      slightly).
      
      In particular, we used to test for overflow using:
        msgs * msgsize + msgs * sizeof(struct msg_msg *)
      
      That was never really correct because each message we allocate via
      load_msg() is actually a struct msg_msg followed by the data for the
      message (and if struct msg_msg + data exceeds PAGE_SIZE we end up
      allocating struct msg_msgseg structs too, but accounting for them would
      get really tedious, so let's ignore those...they're only a pointer in size
      anyway).  This patch updates the calculation to be more accurate in
      regards to maximum possible memory consumption by the mqueue.
      
      [akpm@linux-foundation.org: add a local to simplify overflow-checking expression]
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Cc: Manfred Spraul <manfred@colorfullife.com>
      Acked-by: default avatarKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      2c12ea49
    • Doug Ledford's avatar
      ipc/mqueue: improve performance of send/recv · d6629859
      Doug Ledford authored
      The existing implementation of the POSIX message queue send and recv
      functions is, well, abysmal.  Even worse than abysmal.  I submitted a
      patch to increase the maximum POSIX message queue limit to 65536 due to
      customer needs, however, upon looking over the send/recv implementation, I
      realized that my customer needs help with that too even if they don't know
      it.  The basic problem is that, given the fairly typical use case scenario
      for a large queue of queueing lots of messages all at the same priority (I
      verified with my customer that this is indeed what their app does), the
      msg_insert routine is basically a frikkin' bubble sort.  I mean, whoa,
      that's *so* middle school.
      
      OK, OK, to not slam the original author too much, I'm sure they didn't
      envision a queue depth of 50,000+ messages.  No one would think that
      moving elements in an array, one at a time, and dereferencing each pointer
      in that array to check priority of the message being pointed too, again
      one at a time, for 50,000+ times would be good.  So let's assume that, as
      is typical, the users have found a way to break our code simply by using
      it in a way we didn't envision.  Fair enough.
      
      "So, just how broken is it?", you ask.  I wondered the same thing, so I
      wrote an app to let me know.  It's my next patch.  It gave me some
      interesting results.  Here's what it tested:
      
      Interference with other apps - In continuous mode, the app just sits there
      and hits a message queue forever, while you go do something productive on
      another terminal using other CPUs.  You then measure how long it takes you
      to do that something productive.  Then you restart the app in fake
      continuous mode, and it sits in a tight loop on a CPU while you repeat
      your tests.  The whole point of this is to keep one CPU tied up (so it
      can't be used in your other work) but in one case tied up hitting the
      mqueue code so we can see the effect of walking that 65,528 element array
      one pointer at a time on the global CPU cache.  If it's bad, then it will
      slow down your app on the other CPUs just by polluting cache mercilessly.
      In the fake case, it will be in a tight loop, but not polluting cache.
      Testing the mqueue subsystem directly - Here we just run a number of tests
      to see how the mqueue subsystem performs under different conditions.  A
      couple conditions are known to be worst case for the old system, and some
      routines, so this tests all of them.
      
      So, on to the results already:
      
      Subsystem/Test                  Old                         New
      
      Time to compile linux
      kernel (make -j12 on a
      6 core CPU)
        Running mqueue test     user 49m10.744s             user 45m26.294s
      			   sys  5m51.924s              sys  4m59.894s
      			 total 55m02.668s            total 50m26.188s
      
        Running fake test       user 45m32.686s             user 45m18.552s
                                 sys  5m12.465s              sys  4m56.468s
                               total 50m45.151s            total 50m15.020s
      
        % slowdown from mqueue
          cache thrashing            ~8%                         ~.5%
      
      Avg time to send/recv (in nanoseconds per message)
        when queue empty            305/288                    349/318
        when queue full (65528 messages)
          constant priority      526589/823                    362/314
          increasing priority    403105/916                    495/445
          decreasing priority     73420/594                    482/409
          random priority        280147/920                    546/436
      
      Time to fill/drain queue (65528 messages, in seconds)
        constant priority         17.37/.12                    .13/.12
        increasing priority        4.14/.14                    .21/.18
        decreasing priority       12.93/.13                    .21/.18
        random priority            8.88/.16                    .22/.17
      
      So, I think the results speak for themselves.  It's possible this
      implementation could be improved by cacheing at least one priority level
      in the node tree (that would bring the queue empty performance more in
      line with the old implementation), but this works and is *so* much better
      than what we had, especially for the common case of a single priority in
      use, that further refinements can be in follow on patches.
      
      [akpm@linux-foundation.org: fix typo in comment, remove stray semicolon]
      [levinsasha928@gmail.com: use correct gfp flags in msg_insert]
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Cc: Manfred Spraul <manfred@colorfullife.com>
      Acked-by: default avatarKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Signed-off-by: default avatarSasha Levin <levinsasha928@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      d6629859
    • Doug Ledford's avatar
      selftests: add mq_open_tests · 50069a58
      Doug Ledford authored
      Add a directory to house POSIX message queue subsystem specific tests.
      Add first test which checks the operation of mq_open() under various
      corner conditions.
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Cc: Doug Ledford <dledford@redhat.com>
      Cc: Joe Korty <joe.korty@ccur.com>
      Cc: Amerigo Wang <amwang@redhat.com>
      Cc: Serge E. Hallyn <serue@us.ibm.com>
      Cc: Jiri Slaby <jslaby@suse.cz>
      Cc: Manfred Spraul <manfred@colorfullife.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      50069a58
    • KOSAKI Motohiro's avatar
      mqueue: separate mqueue default value from maximum value · cef0184c
      KOSAKI Motohiro authored
      Commit b231cca4 ("message queues: increase range limits") changed
      mqueue default value when attr parameter is specified NULL from hard
      coded value to fs.mqueue.{msg,msgsize}_max sysctl value.
      
      This made large side effect.  When user need to use two mqueue
      applications 1) using !NULL attr parameter and it require big message
      size and 2) using NULL attr parameter and only need small size message,
      app (1) require to raise fs.mqueue.msgsize_max and app (2) consume large
      memory size even though it doesn't need.
      
      Doug Ledford propsed to switch back it to static hard coded value.
      However it also has a compatibility problem.  Some applications might
      started depend on the default value is tunable.
      
      The solution is to separate default value from maximum value.
      Signed-off-by: default avatarKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Acked-by: default avatarDoug Ledford <dledford@redhat.com>
      Acked-by: default avatarJoe Korty <joe.korty@ccur.com>
      Cc: Amerigo Wang <amwang@redhat.com>
      Acked-by: default avatarSerge E. Hallyn <serue@us.ibm.com>
      Cc: Jiri Slaby <jslaby@suse.cz>
      Cc: Manfred Spraul <manfred@colorfullife.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      cef0184c
    • KOSAKI Motohiro's avatar
      mqueue: don't use kmalloc with KMALLOC_MAX_SIZE · fd1f87d2
      KOSAKI Motohiro authored
      KMALLOC_MAX_SIZE is not a good threshold.  It is extremely high and
      problematic.  Unfortunately, some silly drivers depend on this and we
      can't change it.  But any new code needn't use such extreme ugly high
      order allocations.  It brings us awful fragmentation issues and system
      slowdown.
      Signed-off-by: default avatarKOSAKI Motohiro <mkosaki@jp.fujitsu.com>
      Acked-by: default avatarDoug Ledford <dledford@redhat.com>
      Acked-by: default avatarJoe Korty <joe.korty@ccur.com>
      Cc: Amerigo Wang <amwang@redhat.com>
      Cc: Serge E. Hallyn <serue@us.ibm.com>
      Cc: Jiri Slaby <jslaby@suse.cz>
      Cc: Joe Korty <joe.korty@ccur.com>
      Cc: Manfred Spraul <manfred@colorfullife.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      fd1f87d2
    • KOSAKI Motohiro's avatar
      mqueue: revert bump up DFLT_*MAX · e6315bb1
      KOSAKI Motohiro authored
      Mqueue limitation is slightly naieve parameter likes other ipcs because
      unprivileged user can consume kernel memory by using ipcs.
      
      Thus, too aggressive raise bring us security issue.  Example, current
      setting allow evil unprivileged user use 256GB (= 256 * 1024 * 1024*1024)
      and it's enough large to system will belome unresponsive.  Don't do that.
      
      Instead, every admin should adjust the knobs for their own systems.
      Signed-off-by: default avatarKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Acked-by: default avatarDoug Ledford <dledford@redhat.com>
      Acked-by: default avatarJoe Korty <joe.korty@ccur.com>
      Cc: Amerigo Wang <amwang@redhat.com>
      Acked-by: default avatarSerge E. Hallyn <serue@us.ibm.com>
      Cc: Jiri Slaby <jslaby@suse.cz>
      Cc: Manfred Spraul <manfred@colorfullife.com>
      Cc: Dave Hansen <haveblue@us.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      e6315bb1