1. 09 Sep, 2017 2 commits
    • Luis R. Rodriguez's avatar
      kmod: move #ifdef CONFIG_MODULES wrapper to Makefile · 0ce2c202
      Luis R. Rodriguez authored
      The entire file is now conditionally compiled only when CONFIG_MODULES is
      enabled, and this this is a bool.  Just move this conditional to the
      Makefile as its easier to read this way.
      
      Link: http://lkml.kernel.org/r/20170810180618.22457-5-mcgrof@kernel.orgSigned-off-by: 's avatarLuis R. Rodriguez <mcgrof@kernel.org>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
      Cc: Jessica Yu <jeyu@redhat.com>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Michal Marek <mmarek@suse.com>
      Cc: Petr Mladek <pmladek@suse.com>
      Cc: Miroslav Benes <mbenes@suse.cz>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Matt Redfearn <matt.redfearn@imgtec.com>
      Cc: Dan Carpenter <dan.carpenter@oracle.com>
      Cc: Colin Ian King <colin.king@canonical.com>
      Cc: Daniel Mentz <danielmentz@google.com>
      Cc: David Binderman <dcb314@hotmail.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: 's avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      0ce2c202
    • Luis R. Rodriguez's avatar
      kmod: split out umh code into its own file · 23558693
      Luis R. Rodriguez authored
      Patch series "kmod: few code cleanups to split out umh code"
      
      The usermode helper has a provenance from the old usb code which first
      required a usermode helper.  Eventually this was shoved into kmod.c and
      the kernel's modprobe calls was converted over eventually to share the
      same code.  Over time the list of usermode helpers in the kernel has grown
      -- so kmod is just but one user of the API.
      
      This series is a simple logical cleanup which acknowledges the code
      evolution of the usermode helper and shoves the UMH API into its own
      dedicated file.  This way users of the API can later just include umh.h
      instead of kmod.h.
      
      Note despite the diff state the first patch really is just a code shove,
      no functional changes are done there.  I did use git format-patch -M to
      generate the patch, but in the end the split was not enough for git to
      consider it a rename hence the large diffstat.
      
      I've put this through 0-day and it gives me their machine compilation
      blessings with all tests as OK.
      
      This patch (of 4):
      
      There's a slew of usermode helper users and kmod is just one of them.
      Split out the usermode helper code into its own file to keep the logic and
      focus split up.
      
      This change provides no functional changes.
      
      Link: http://lkml.kernel.org/r/20170810180618.22457-2-mcgrof@kernel.orgSigned-off-by: 's avatarLuis R. Rodriguez <mcgrof@kernel.org>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
      Cc: Jessica Yu <jeyu@redhat.com>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Michal Marek <mmarek@suse.com>
      Cc: Petr Mladek <pmladek@suse.com>
      Cc: Miroslav Benes <mbenes@suse.cz>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Matt Redfearn <matt.redfearn@imgtec.com>
      Cc: Dan Carpenter <dan.carpenter@oracle.com>
      Cc: Colin Ian King <colin.king@canonical.com>
      Cc: Daniel Mentz <danielmentz@google.com>
      Cc: David Binderman <dcb314@hotmail.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: 's avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      23558693
  2. 18 Aug, 2017 1 commit
    • Luis R. Rodriguez's avatar
      kmod: fix wait on recursive loop · 2ba293c9
      Luis R. Rodriguez authored
      Recursive loops with module loading were previously handled in kmod by
      restricting the number of modprobe calls to 50 and if that limit was
      breached request_module() would return an error and a user would see the
      following on their kernel dmesg:
      
        request_module: runaway loop modprobe binfmt-464c
        Starting init:/sbin/init exists but couldn't execute it (error -8)
      
      This issue could happen for instance when a 64-bit kernel boots a 32-bit
      userspace on some architectures and has no 32-bit binary format
      hanlders.  This is visible, for instance, when a CONFIG_MODULES enabled
      64-bit MIPS kernel boots a into o32 root filesystem and the binfmt
      handler for o32 binaries is not built-in.
      
      After commit 6d7964a7 ("kmod: throttle kmod thread limit") we now
      don't have any visible signs of an error and the kernel just waits for
      the loop to end somehow.
      
      Although this *particular* recursive loop could also be addressed by
      doing a sanity check on search_binary_handler() and disallowing a
      modular binfmt to be required for modprobe, a generic solution for any
      recursive kernel kmod issues is still needed.
      
      This should catch these loops.  We can investigate each loop and address
      each one separately as they come in, this however puts a stop gap for
      them as before.
      
      Link: http://lkml.kernel.org/r/20170809234635.13443-3-mcgrof@kernel.org
      Fixes: 6d7964a7 ("kmod: throttle kmod thread limit")
      Signed-off-by: 's avatarLuis R. Rodriguez <mcgrof@kernel.org>
      Reported-by: 's avatarMatt Redfearn <matt.redfearn@imgtec.com>
      Tested-by: 's avatarMatt Redfearn <matt.redfearn@imgetc.com>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Colin Ian King <colin.king@canonical.com>
      Cc: Dan Carpenter <dan.carpenter@oracle.com>
      Cc: Daniel Mentz <danielmentz@google.com>
      Cc: David Binderman <dcb314@hotmail.com>
      Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Jessica Yu <jeyu@redhat.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Michal Marek <mmarek@suse.com>
      Cc: Miroslav Benes <mbenes@suse.cz>
      Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Petr Mladek <pmladek@suse.com>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Shuah Khan <shuah@kernel.org>
      Signed-off-by: 's avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      2ba293c9
  3. 14 Jul, 2017 1 commit
    • Luis R. Rodriguez's avatar
      kmod: throttle kmod thread limit · 6d7964a7
      Luis R. Rodriguez authored
      If we reach the limit of modprobe_limit threads running the next
      request_module() call will fail.  The original reason for adding a kill
      was to do away with possible issues with in old circumstances which would
      create a recursive series of request_module() calls.
      
      We can do better than just be super aggressive and reject calls once we've
      reached the limit by simply making pending callers wait until the
      threshold has been reduced, and then throttling them in, one by one.
      
      This throttling enables requests over the kmod concurrent limit to be
      processed once a pending request completes.  Only the first item queued up
      to wait is woken up.  The assumption here is once a task is woken it will
      have no other option to also kick the queue to check if there are more
      pending tasks -- regardless of whether or not it was successful.
      
      By throttling and processing only max kmod concurrent tasks we ensure we
      avoid unexpected fatal request_module() calls, and we keep memory
      consumption on module loading to a minimum.
      
      With x86_64 qemu, with 4 cores, 4 GiB of RAM it takes the following run
      time to run both tests:
      
      time ./kmod.sh -t 0008
      real    0m16.366s
      user    0m0.883s
      sys     0m8.916s
      
      time ./kmod.sh -t 0009
      real    0m50.803s
      user    0m0.791s
      sys     0m9.852s
      
      Link: http://lkml.kernel.org/r/20170628223155.26472-4-mcgrof@kernel.orgSigned-off-by: 's avatarLuis R. Rodriguez <mcgrof@kernel.org>
      Reviewed-by: 's avatarPetr Mladek <pmladek@suse.com>
      Cc: Jessica Yu <jeyu@redhat.com>
      Cc: Shuah Khan <shuah@kernel.org>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Michal Marek <mmarek@suse.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: 's avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      6d7964a7
  4. 27 Jun, 2017 1 commit
    • Luis R. Rodriguez's avatar
      kmod: reduce atomic operations on kmod_concurrent and simplify · 165d1cc0
      Luis R. Rodriguez authored
      When checking if we want to allow a kmod thread to kick off we increment,
      then read to see if we should enable a thread. If we were over the allowed
      limit limit we decrement. Splitting the increment far apart from decrement
      means there could be a time where two increments happen potentially
      giving a false failure on a thread which should have been allowed.
      
      CPU1			CPU2
      atomic_inc()
      			atomic_inc()
      atomic_read()
      			atomic_read()
      atomic_dec()
      			atomic_dec()
      
      In this case a read on CPU1 gets the atomic_inc()'s and we could negate
      it from getting a kmod thread. We could try to prevent this with a lock
      or preemption but that is overkill. We can fix by reducing the number of
      atomic operations. We do this by inverting the logic of of the enabler,
      instead of incrementing kmod_concurrent as we get new kmod users, define the
      variable kmod_concurrent_max as the max number of currently allowed kmod
      users and as we get new kmod users just decrement it if its still positive.
      This combines the dec and read in one atomic operation.
      
      In this case we no longer get the same false failure:
      
      CPU1			CPU2
      atomic_dec_if_positive()
      			atomic_dec_if_positive()
      atomic_inc()
      			atomic_inc()
      
      The number of threads is computed at init, and since the current computation
      of kmod_concurrent includes the thread count we can avoid setting
      kmod_concurrent_max later in boot through an init call by simply sticking to
      50 as the kmod_concurrent_max. The assumption here is a system with modules
      must at least have ~16 MiB of RAM.
      Suggested-by: 's avatarPetr Mladek <pmladek@suse.com>
      Suggested-by: 's avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: 's avatarLuis R. Rodriguez <mcgrof@kernel.org>
      Reviewed-by: 's avatarPetr Mladek <pmladek@suse.com>
      Signed-off-by: 's avatarJessica Yu <jeyu@kernel.org>
      165d1cc0
  5. 02 Mar, 2017 2 commits
  6. 19 Jan, 2017 2 commits
    • Greg Kroah-Hartman's avatar
      Introduce STATIC_USERMODEHELPER to mediate call_usermodehelper() · 64e90a8a
      Greg Kroah-Hartman authored
      Some usermode helper applications are defined at kernel build time, while
      others can be changed at runtime.  To provide a sane way to filter these, add a
      new kernel option "STATIC_USERMODEHELPER".  This option routes all
      call_usermodehelper() calls through this binary, no matter what the caller
      wishes to have called.
      
      The new binary (by default set to /sbin/usermode-helper, but can be changed
      through the STATIC_USERMODEHELPER_PATH option) can properly filter the
      requested programs to be run by the kernel by looking at the first argument
      that is passed to it.  All other options should then be passed onto the proper
      program if so desired.
      
      To disable all call_usermodehelper() calls by the kernel, set
      STATIC_USERMODEHELPER_PATH to an empty string.
      
      Thanks to Neil Brown for the idea of this feature.
      
      Cc: NeilBrown <neilb@suse.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      64e90a8a
    • Greg Kroah-Hartman's avatar
      kmod: make usermodehelper path a const string · 6d2c5d6c
      Greg Kroah-Hartman authored
      This is in preparation for making it so that usermode helper programs
      can't be changed, if desired, by userspace.  We will tackle the mess of
      cleaning up the write-ability of argv and env later, that's going to
      take more work, for much less gain...
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6d2c5d6c
  7. 24 Dec, 2016 1 commit
  8. 23 Oct, 2015 1 commit
  9. 10 Sep, 2015 6 commits
    • Frederic Weisbecker's avatar
      kmod: handle UMH_WAIT_PROC from system unbound workqueue · bb304a5c
      Frederic Weisbecker authored
      The UMH_WAIT_PROC handler runs in its own thread in order to make sure
      that waiting for the exec kernel thread completion won't block other
      usermodehelper queued jobs.
      
      On older workqueue implementations, worklets couldn't sleep without
      blocking the rest of the queue.  But now the workqueue subsystem handles
      that.  Khelper still had the older limitation due to its singlethread
      properties but we replaced it to system unbound workqueues.
      
      Those are affine to the current node and can block up to some number of
      instances.
      
      They are a good candidate to handle UMH_WAIT_PROC assuming that we have
      enough system unbound workers to handle lots of parallel usermodehelper
      jobs.
      Signed-off-by: 's avatarFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Rik van Riel <riel@redhat.com>
      Reviewed-by: 's avatarOleg Nesterov <oleg@redhat.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: 's avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      bb304a5c
    • Frederic Weisbecker's avatar
      kmod: use system_unbound_wq instead of khelper · 90f02303
      Frederic Weisbecker authored
      We need to launch the usermodehelper kernel threads with the widest
      affinity and this is partly why we use khelper.  This workqueue has
      unbound properties and thus a wide affinity inherited by all its children.
      
      Now khelper also has special properties that we aren't much interested in:
      ordered and singlethread.  There is really no need about ordering as all
      we do is creating kernel threads.  This can be done concurrently.  And
      singlethread is a useless limitation as well.
      
      The workqueue engine already proposes generic unbound workqueues that
      don't share these useless properties and handle well parallel jobs.
      
      The only worrysome specific is their affinity to the node of the current
      CPU.  It's fine for creating the usermodehelper kernel threads but those
      inherit this affinity for longer jobs such as requesting modules.
      
      This patch proposes to use these node affine unbound workqueues assuming
      that a node is sufficient to handle several parallel usermodehelper
      requests.
      Signed-off-by: 's avatarFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Rik van Riel <riel@redhat.com>
      Reviewed-by: 's avatarOleg Nesterov <oleg@redhat.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: 's avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      90f02303
    • Frederic Weisbecker's avatar
      kmod: add up-to-date explanations on the purpose of each asynchronous levels · b639e86b
      Frederic Weisbecker authored
      There seem to be quite some confusions on the comments, likely due to
      changes that came after them.
      
      Now since it's very non obvious why we have 3 levels of asynchronous code
      to implement usermodehelpers, it's important to comment in detail the
      reason of this layout.
      Signed-off-by: 's avatarFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Rik van Riel <riel@redhat.com>
      Reviewed-by: 's avatarOleg Nesterov <oleg@redhat.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: 's avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      b639e86b
    • Frederic Weisbecker's avatar
      kmod: remove unecessary explicit wide CPU affinity setting · d097c024
      Frederic Weisbecker authored
      Khelper is affine to all CPUs.  Now since it creates the
      call_usermodehelper_exec_[a]sync() kernel threads, those inherit the wide
      affinity.
      
      As such explicitly forcing a wide affinity from those kernel threads
      is like a no-op.
      
      Just remove it. It's needless and it breaks CPU isolation users who
      rely on workqueue affinity tuning.
      Signed-off-by: 's avatarFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Rik van Riel <riel@redhat.com>
      Reviewed-by: 's avatarOleg Nesterov <oleg@redhat.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: 's avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      d097c024
    • Frederic Weisbecker's avatar
      kmod: bunch of internal functions renames · b6b50a81
      Frederic Weisbecker authored
      This patchset does a bunch of cleanups and converts khelper to use system
      unbound workqueues.  The 3 first patches should be uncontroversial.  The
      last 2 patches are debatable.
      
      Kmod creates kernel threads that perform userspace jobs and we want those
      to have a large affinity in order not to contend busy CPUs.  This is
      (partly) why we use khelper which has a wide affinity that the kernel
      threads it create can inherit from.  Now khelper is a dedicated workqueue
      that has singlethread properties which we aren't interested in.
      
      Hence those two debatable changes:
      
      _ We would like to use generic workqueues. System unbound workqueues are
        a very good candidate but they are not wide affine, only node affine.
        Now probably a node is enough to perform many parallel kmod jobs.
      
      _ We would like to remove the wait_for_helper kernel thread (UMH_WAIT_PROC
        handler) to use the workqueue. It means that if the workqueue blocks,
        and no other worker can take pending kmod request, we can be screwed.
        Now if we have 512 threads, this should be enough.
      
      This patch (of 5):
      
      Underscores on function names aren't much verbose to explain the purpose
      of a function.  And kmod has interesting such flavours.
      
      Lets rename the following functions:
      
      * __call_usermodehelper -> call_usermodehelper_exec_work
      * ____call_usermodehelper -> call_usermodehelper_exec_async
      * wait_for_helper -> call_usermodehelper_exec_sync
      Signed-off-by: 's avatarFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Rik van Riel <riel@redhat.com>
      Reviewed-by: 's avatarOleg Nesterov <oleg@redhat.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: 's avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      b6b50a81
    • NeilBrown's avatar
      kmod: correct documentation of return status of request_module · 60b61a6f
      NeilBrown authored
      If request_module() successfully runs modprobe, but modprobe exits with a
      non-zero status, then the return value from request_module() will be that
      (positive) error status.  So the return from request_module can be:
      
       negative errno
       zero for success
       positive exit code.
      Signed-off-by: 's avatarNeilBrown <neilb@suse.com>
      Cc: Goldwyn Rodrigues <rgoldwyn@suse.de>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: 's avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      60b61a6f
  10. 11 Dec, 2014 2 commits
  11. 29 Oct, 2014 1 commit
    • Martin Schwidefsky's avatar
      kernel/kmod: fix use-after-free of the sub_info structure · 0baf2a4d
      Martin Schwidefsky authored
      Found this in the message log on a s390 system:
      
          BUG kmalloc-192 (Not tainted): Poison overwritten
          Disabling lock debugging due to kernel taint
          INFO: 0x00000000684761f4-0x00000000684761f7. First byte 0xff instead of 0x6b
          INFO: Allocated in call_usermodehelper_setup+0x70/0x128 age=71 cpu=2 pid=648
           __slab_alloc.isra.47.constprop.56+0x5f6/0x658
           kmem_cache_alloc_trace+0x106/0x408
           call_usermodehelper_setup+0x70/0x128
           call_usermodehelper+0x62/0x90
           cgroup_release_agent+0x178/0x1c0
           process_one_work+0x36e/0x680
           worker_thread+0x2f0/0x4f8
           kthread+0x10a/0x120
           kernel_thread_starter+0x6/0xc
           kernel_thread_starter+0x0/0xc
          INFO: Freed in call_usermodehelper_exec+0x110/0x1b8 age=71 cpu=2 pid=648
           __slab_free+0x94/0x560
           kfree+0x364/0x3e0
           call_usermodehelper_exec+0x110/0x1b8
           cgroup_release_agent+0x178/0x1c0
           process_one_work+0x36e/0x680
           worker_thread+0x2f0/0x4f8
           kthread+0x10a/0x120
           kernel_thread_starter+0x6/0xc
           kernel_thread_starter+0x0/0xc
      
      There is a use-after-free bug on the subprocess_info structure allocated
      by the user mode helper.  In case do_execve() returns with an error
      ____call_usermodehelper() stores the error code to sub_info->retval, but
      sub_info can already have been freed.
      
      Regarding UMH_NO_WAIT, the sub_info structure can be freed by
      __call_usermodehelper() before the worker thread returns from
      do_execve(), allowing memory corruption when do_execve() failed after
      exec_mmap() is called.
      
      Regarding UMH_WAIT_EXEC, the call to umh_complete() allows
      call_usermodehelper_exec() to continue which then frees sub_info.
      
      To fix this race the code needs to make sure that the call to
      call_usermodehelper_freeinfo() is always done after the last store to
      sub_info->retval.
      Signed-off-by: 's avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Reviewed-by: 's avatarOleg Nesterov <oleg@redhat.com>
      Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
      Signed-off-by: 's avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      0baf2a4d
  12. 06 Jun, 2014 1 commit
  13. 18 Apr, 2014 1 commit
  14. 05 Feb, 2014 1 commit
    • Linus Torvalds's avatar
      execve: use 'struct filename *' for executable name passing · c4ad8f98
      Linus Torvalds authored
      This changes 'do_execve()' to get the executable name as a 'struct
      filename', and to free it when it is done.  This is what the normal
      users want, and it simplifies and streamlines their error handling.
      
      The controlled lifetime of the executable name also fixes a
      use-after-free problem with the trace_sched_process_exec tracepoint: the
      lifetime of the passed-in string for kernel users was not at all
      obvious, and the user-mode helper code used UMH_WAIT_EXEC to serialize
      the pathname allocation lifetime with the execve() having finished,
      which in turn meant that the trace point that happened after
      mm_release() of the old process VM ended up using already free'd memory.
      
      To solve the kernel string lifetime issue, this simply introduces
      "getname_kernel()" that works like the normal user-space getname()
      function, except with the source coming from kernel memory.
      
      As Oleg points out, this also means that we could drop the tcomm[] array
      from 'struct linux_binprm', since the pathname lifetime now covers
      setup_new_exec().  That would be a separate cleanup.
      Reported-by: 's avatarIgor Zhbanov <i.zhbanov@samsung.com>
      Tested-by: 's avatarSteven Rostedt <rostedt@goodmis.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      c4ad8f98
  15. 30 Sep, 2013 1 commit
  16. 03 Jul, 2013 1 commit
  17. 16 May, 2013 1 commit
  18. 01 May, 2013 3 commits
  19. 23 Jan, 2013 1 commit
    • Tejun Heo's avatar
      async, kmod: warn on synchronous request_module() from async workers · 0fdff3ec
      Tejun Heo authored
      Synchronous requet_module() from an async worker can lead to deadlock
      because module init path may invoke async_synchronize_full().  The
      async worker waits for request_module() to complete and the module
      loading waits for the async task to finish.  This bug happened in the
      block layer because of default elevator auto-loading.
      
      Block layer has been updated not to do default elevator auto-loading
      and it has been decided to disallow synchronous request_module() from
      async workers.
      
      Trigger WARN_ON_ONCE() on synchronous request_module() from async
      workers.
      
      For more details, please refer to the following thread.
      
        http://thread.gmane.org/gmane.linux.kernel/1420814Signed-off-by: 's avatarTejun Heo <tj@kernel.org>
      Reported-by: 's avatarAlex Riesen <raa.lkml@gmail.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      0fdff3ec
  20. 19 Dec, 2012 1 commit
  21. 12 Oct, 2012 2 commits
    • Al Viro's avatar
      infrastructure for saner ret_from_kernel_thread semantics · a74fb73c
      Al Viro authored
      * allow kernel_execve() leave the actual return to userland to
      caller (selected by CONFIG_GENERIC_KERNEL_EXECVE).  Callers
      updated accordingly.
      * architecture that does select GENERIC_KERNEL_EXECVE in its
      Kconfig should have its ret_from_kernel_thread() do this:
      	call schedule_tail
      	call the callback left for it by copy_thread(); if it ever
      returns, that's because it has just done successful kernel_execve()
      	jump to return from syscall
      IOW, its only difference from ret_from_fork() is that it does call the
      callback.
      * such an architecture should also get rid of ret_from_kernel_execve()
      and __ARCH_WANT_KERNEL_EXECVE
      
      This is the last part of infrastructure patches in that area - from
      that point on work on different architectures can live independently.
      Signed-off-by: 's avatarAl Viro <viro@zeniv.linux.org.uk>
      a74fb73c
    • Al Viro's avatar
      make sure that kernel_thread() callbacks call do_exit() themselves · fb45550d
      Al Viro authored
      Most of them never returned anyway - only two functions had to be
      changed.  That allows to simplify their callers a whole lot.
      
      Note that this does *not* apply to kthread_run() callbacks - all of
      those had been called from the same kernel_thread() callback, which
      did do_exit() already.  This is strictly about very few low-level
      kernel_thread() callbacks (there are only 6 of those, mostly as part
      of kthread.h and kmod.h exported mechanisms, plus kernel_init()
      itself).
      Signed-off-by: 's avatarAl Viro <viro@zeniv.linux.org.uk>
      fb45550d
  22. 31 Jul, 2012 2 commits
    • Tetsuo Handa's avatar
      kmod: avoid deadlock from recursive kmod call · 0f20784d
      Tetsuo Handa authored
      The system deadlocks (at least since 2.6.10) when
      call_usermodehelper(UMH_WAIT_EXEC) request triggers
      call_usermodehelper(UMH_WAIT_PROC) request.
      
      This is because "khelper thread is waiting for the worker thread at
      wait_for_completion() in do_fork() since the worker thread was created
      with CLONE_VFORK flag" and "the worker thread cannot call complete()
      because do_execve() is blocked at UMH_WAIT_PROC request" and "the khelper
      thread cannot start processing UMH_WAIT_PROC request because the khelper
      thread is waiting for the worker thread at wait_for_completion() in
      do_fork()".
      
      The easiest example to observe this deadlock is to use a corrupted
      /sbin/hotplug binary (like shown below).
      
        # : > /tmp/dummy
        # chmod 755 /tmp/dummy
        # echo /tmp/dummy > /proc/sys/kernel/hotplug
        # modprobe whatever
      
      call_usermodehelper("/tmp/dummy", UMH_WAIT_EXEC) is called from
      kobject_uevent_env() in lib/kobject_uevent.c upon loading/unloading a
      module.  do_execve("/tmp/dummy") triggers a call to
      request_module("binfmt-0000") from search_binary_handler() which in turn
      calls call_usermodehelper(UMH_WAIT_PROC).
      
      In order to avoid deadlock, as a for-now and easy-to-backport solution, do
      not try to call wait_for_completion() in call_usermodehelper_exec() if the
      worker thread was created by khelper thread with CLONE_VFORK flag.  Future
      and fundamental solution might be replacing singleton khelper thread with
      some workqueue so that recursive calls up to max_active dependency loop
      can be handled without deadlock.
      
      [akpm@linux-foundation.org: add comment to kmod_thread_locker]
      Signed-off-by: 's avatarTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Acked-by: 's avatarRusty Russell <rusty@rustcorp.com.au>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Signed-off-by: 's avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      0f20784d
    • Andrew Morton's avatar
      kernel/kmod.c: document call_usermodehelper_fns() a bit · 79c743dd
      Andrew Morton authored
      This function's interface is, uh, subtle.  Attempt to apologise for it.
      
      Cc: WANG Cong <xiyou.wangcong@gmail.com>
      Cc: Cyrill Gorcunov <gorcunov@openvz.org>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Serge Hallyn <serge.hallyn@canonical.com>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: 's avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      79c743dd
  23. 01 Jun, 2012 3 commits
  24. 28 Mar, 2012 2 commits
    • Rafael J. Wysocki's avatar
      PM / Sleep: Mitigate race between the freezer and request_firmware() · 247bc037
      Rafael J. Wysocki authored
      There is a race condition between the freezer and request_firmware()
      such that if request_firmware() is run on one CPU and
      freeze_processes() is run on another CPU and usermodehelper_disable()
      called by it succeeds to grab umhelper_sem for writing before
      usermodehelper_read_trylock() called from request_firmware()
      acquires it for reading, the request_firmware() will fail and
      trigger a WARN_ON() complaining that it was called at a wrong time.
      However, in fact, it wasn't called at a wrong time and
      freeze_processes() simply happened to be executed simultaneously.
      
      To avoid this race, at least in some cases, modify
      usermodehelper_read_trylock() so that it doesn't fail if the
      freezing of tasks has just started and hasn't been completed yet.
      Instead, during the freezing of tasks, it will try to freeze the
      task that has called it so that it can wait until user space is
      thawed without triggering the scary warning.
      
      For this purpose, change usermodehelper_disabled so that it can
      take three different values, UMH_ENABLED (0), UMH_FREEZING and
      UMH_DISABLED.  The first one means that usermode helpers are
      enabled, the last one means "hard disable" (i.e. the system is not
      ready for usermode helpers to be used) and the second one
      is reserved for the freezer.  Namely, when freeze_processes() is
      started, it sets usermodehelper_disabled to UMH_FREEZING which
      tells usermodehelper_read_trylock() that it shouldn't fail just
      yet and should call try_to_freeze() if woken up and cannot
      return immediately.  This way all freezable tasks that happen
      to call request_firmware() right before freeze_processes() is
      started and lose the race for umhelper_sem with it will be
      frozen and will sleep until thaw_processes() unsets
      usermodehelper_disabled.  [For the non-freezable callers of
      request_firmware() the race for umhelper_sem against
      freeze_processes() is unfortunately unavoidable.]
      Reported-by: 's avatarStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: 's avatarRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: stable@vger.kernel.org
      247bc037
    • Rafael J. Wysocki's avatar
      firmware_class: Do not warn that system is not ready from async loads · 9b78c1da
      Rafael J. Wysocki authored
      If firmware is requested asynchronously, by calling
      request_firmware_nowait(), there is no reason to fail the request
      (and warn the user) when the system is (presumably temporarily)
      unready to handle it (because user space is not available yet or
      frozen).  For this reason, introduce an alternative routine for
      read-locking umhelper_sem, usermodehelper_read_lock_wait(), that
      will wait for usermodehelper_disabled to be unset (possibly with
      a timeout) and make request_firmware_work_func() use it instead of
      usermodehelper_read_trylock().
      
      Accordingly, modify request_firmware() so that it uses
      usermodehelper_read_trylock() to acquire umhelper_sem and remove
      the code related to that lock from _request_firmware().
      Signed-off-by: 's avatarRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: stable@vger.kernel.org
      9b78c1da