1. 12 10月, 2016 4 次提交
    • P
      kthread: allow to call __kthread_create_on_node() with va_list args · 255451e4
      Petr Mladek 提交于
      kthread_create_on_node() implements a bunch of logic to create the
      kthread.  It is already called by kthread_create_on_cpu().
      
      We are going to extend the kthread worker API and will need to call
      kthread_create_on_node() with va_list args there.
      
      This patch does only a refactoring and does not modify the existing
      behavior.
      
      Link: http://lkml.kernel.org/r/1470754545-17632-5-git-send-email-pmladek@suse.comSigned-off-by: NPetr Mladek <pmladek@suse.com>
      Acked-by: NTejun Heo <tj@kernel.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Cc: Josh Triplett <josh@joshtriplett.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Michal Hocko <mhocko@suse.cz>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      255451e4
    • P
      kthread/smpboot: do not park in kthread_create_on_cpu() · a65d4096
      Petr Mladek 提交于
      kthread_create_on_cpu() was added by the commit 2a1d4460
      ("kthread: Implement park/unpark facility").  It is currently used only
      when enabling new CPU.  For this purpose, the newly created kthread has to
      be parked.
      
      The CPU binding is a bit tricky.  The kthread is parked when the CPU has
      not been allowed yet.  And the CPU is bound when the kthread is unparked.
      
      The function would be useful for more per-CPU kthreads, e.g.
      bnx2fc_thread, fcoethread.  For this purpose, the newly created kthread
      should stay in the uninterruptible state.
      
      This patch moves the parking into smpboot.  It binds the thread already
      when created.  Then the function might be used universally.  Also the
      behavior is consistent with kthread_create() and kthread_create_on_node().
      
      Link: http://lkml.kernel.org/r/1470754545-17632-4-git-send-email-pmladek@suse.comSigned-off-by: NPetr Mladek <pmladek@suse.com>
      Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Cc: Josh Triplett <josh@joshtriplett.org>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Michal Hocko <mhocko@suse.cz>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a65d4096
    • P
      kthread: kthread worker API cleanup · 3989144f
      Petr Mladek 提交于
      A good practice is to prefix the names of functions by the name
      of the subsystem.
      
      The kthread worker API is a mix of classic kthreads and workqueues.  Each
      worker has a dedicated kthread.  It runs a generic function that process
      queued works.  It is implemented as part of the kthread subsystem.
      
      This patch renames the existing kthread worker API to use
      the corresponding name from the workqueues API prefixed by
      kthread_:
      
      __init_kthread_worker()		-> __kthread_init_worker()
      init_kthread_worker()		-> kthread_init_worker()
      init_kthread_work()		-> kthread_init_work()
      insert_kthread_work()		-> kthread_insert_work()
      queue_kthread_work()		-> kthread_queue_work()
      flush_kthread_work()		-> kthread_flush_work()
      flush_kthread_worker()		-> kthread_flush_worker()
      
      Note that the names of DEFINE_KTHREAD_WORK*() macros stay
      as they are. It is common that the "DEFINE_" prefix has
      precedence over the subsystem names.
      
      Note that INIT() macros and init() functions use different
      naming scheme. There is no good solution. There are several
      reasons for this solution:
      
        + "init" in the function names stands for the verb "initialize"
          aka "initialize worker". While "INIT" in the macro names
          stands for the noun "INITIALIZER" aka "worker initializer".
      
        + INIT() macros are used only in DEFINE() macros
      
        + init() functions are used close to the other kthread()
          functions. It looks much better if all the functions
          use the same scheme.
      
        + There will be also kthread_destroy_worker() that will
          be used close to kthread_cancel_work(). It is related
          to the init() function. Again it looks better if all
          functions use the same naming scheme.
      
        + there are several precedents for such init() function
          names, e.g. amd_iommu_init_device(), free_area_init_node(),
          jump_label_init_type(),  regmap_init_mmio_clk(),
      
        + It is not an argument but it was inconsistent even before.
      
      [arnd@arndb.de: fix linux-next merge conflict]
       Link: http://lkml.kernel.org/r/20160908135724.1311726-1-arnd@arndb.de
      Link: http://lkml.kernel.org/r/1470754545-17632-3-git-send-email-pmladek@suse.comSuggested-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NPetr Mladek <pmladek@suse.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Cc: Josh Triplett <josh@joshtriplett.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Michal Hocko <mhocko@suse.cz>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3989144f
    • P
      kthread: rename probe_kthread_data() to kthread_probe_data() · e700591a
      Petr Mladek 提交于
      Patch series "kthread: Kthread worker API improvements"
      
      The intention of this patchset is to make it easier to manipulate and
      maintain kthreads.  Especially, I want to replace all the custom main
      cycles with a generic one.  Also I want to make the kthreads sleep in a
      consistent state in a common place when there is no work.
      
      This patch (of 11):
      
      A good practice is to prefix the names of functions by the name of the
      subsystem.
      
      This patch fixes the name of probe_kthread_data().  The other wrong
      functions names are part of the kthread worker API and will be fixed
      separately.
      
      Link: http://lkml.kernel.org/r/1470754545-17632-2-git-send-email-pmladek@suse.comSigned-off-by: NPetr Mladek <pmladek@suse.com>
      Suggested-by: NAndrew Morton <akpm@linux-foundation.org>
      Acked-by: NTejun Heo <tj@kernel.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Cc: Josh Triplett <josh@joshtriplett.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Michal Hocko <mhocko@suse.cz>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e700591a
  2. 16 9月, 2016 1 次提交
  3. 05 9月, 2015 1 次提交
  4. 12 8月, 2015 1 次提交
  5. 07 8月, 2015 1 次提交
  6. 10 10月, 2014 1 次提交
    • N
      kernel/kthread.c: partial revert of 81c98869 ("kthread: ensure locality of... · 10922838
      Nishanth Aravamudan 提交于
      kernel/kthread.c: partial revert of 81c98869 ("kthread: ensure locality of task_struct allocations")
      
      After discussions with Tejun, we don't want to spread the use of
      cpu_to_mem() (and thus knowledge of allocators/NUMA topology details) into
      callers, but would rather ensure the callees correctly handle memoryless
      nodes.  With the previous patches ("topology: add support for
      node_to_mem_node() to determine the fallback node" and "slub: fallback to
      node_to_mem_node() node if allocating on memoryless node") adding and
      using node_to_mem_node(), we can safely undo part of the change to the
      kthread logic from 81c98869.
      Signed-off-by: NNishanth Aravamudan <nacc@linux.vnet.ibm.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Han Pingtian <hanpt@linux.vnet.ibm.com>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Anton Blanchard <anton@samba.org>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Wanpeng Li <liwanp@linux.vnet.ibm.com>
      Cc: Tejun Heo <tj@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      10922838
  7. 29 7月, 2014 1 次提交
  8. 05 6月, 2014 1 次提交
  9. 04 4月, 2014 1 次提交
  10. 13 11月, 2013 1 次提交
  11. 01 5月, 2013 1 次提交
    • T
      kthread: implement probe_kthread_data() · cd42d559
      Tejun Heo 提交于
      One of the problems that arise when converting dedicated custom threadpool
      to workqueue is that the shared worker pool used by workqueue anonimizes
      each worker making it more difficult to identify what the worker was doing
      on which target from the output of sysrq-t or debug dump from oops, BUG()
      and friends.
      
      For example, after writeback is converted to use workqueue instead of
      priviate thread pool, there's no easy to tell which backing device a
      writeback work item was working on at the time of task dump, which,
      according to our writeback brethren, is important in tracking down issues
      with a lot of mounted file systems on a lot of different devices.
      
      This patchset implements a way for a work function to mark its execution
      instance so that task dump of the worker task includes information to
      indicate what the work item was doing.
      
      An example WARN dump would look like the following.
      
       WARNING: at fs/fs-writeback.c:1015 bdi_writeback_workfn+0x2b4/0x3c0()
       Modules linked in:
       CPU: 0 Pid: 28 Comm: kworker/u18:0 Not tainted 3.9.0-rc1-work+ #24
       Hardware name: empty empty/S3992, BIOS 080011  10/26/2007
       Workqueue: writeback bdi_writeback_workfn (flush-8:16)
        ffffffff820a3a98 ffff88015b927cb8 ffffffff81c61855 ffff88015b927cf8
        ffffffff8108f500 0000000000000000 ffff88007a171948 ffff88007a1716b0
        ffff88015b49df00 ffff88015b8d3940 0000000000000000 ffff88015b927d08
       Call Trace:
        [<ffffffff81c61855>] dump_stack+0x19/0x1b
        [<ffffffff8108f500>] warn_slowpath_common+0x70/0xa0
        ...
      
      This patch:
      
      Implement probe_kthread_data() which returns kthread_data if accessible.
      The function is equivalent to kthread_data() except that the specified
      @task may not be a kthread or its vfork_done is already cleared rendering
      struct kthread inaccessible.  In the former case, probe_kthread_data() may
      return any value.  In the latter, NULL.
      
      This will be used to safely print debug information without affecting
      synchronization in the normal paths.  Workqueue debug info printing on
      dump_stack() and friends will make use of it.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Acked-by: NJan Kara <jack@suse.cz>
      Cc: Dave Chinner <david@fromorbit.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      cd42d559
  12. 30 4月, 2013 2 次提交
    • O
      kthread: kill task_get_live_kthread() · b5c5442b
      Oleg Nesterov 提交于
      task_get_live_kthread() looks confusing and unneeded.  It does
      get_task_struct() but only kthread_stop() needs this, it can be called
      even if the calller doesn't have a reference when we know that this
      kthread can't exit until we do kthread_stop().
      
      kthread_park() and kthread_unpark() do not need get_task_struct(), the
      callers already have the reference.  And it can not help if we can race
      with the exiting kthread anyway, kthread_park() can hang forever in this
      case.
      
      Change kthread_park() and kthread_unpark() to use to_live_kthread(),
      change kthread_stop() to do get_task_struct() by hand and remove
      task_get_live_kthread().
      Signed-off-by: NOleg Nesterov <oleg@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
      Cc: Tejun Heo <tj@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b5c5442b
    • O
      kthread: introduce to_live_kthread() · 4ecdafc8
      Oleg Nesterov 提交于
      "k->vfork_done != NULL" with a barrier() after to_kthread(k) in
      task_get_live_kthread(k) looks unclear, and sub-optimal because we load
      ->vfork_done twice.
      
      All we need is to ensure that we do not return to_kthread(NULL).  Add a
      new trivial helper which loads/checks ->vfork_done once, this also looks
      more understandable.
      Signed-off-by: NOleg Nesterov <oleg@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
      Cc: Tejun Heo <tj@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4ecdafc8
  13. 12 4月, 2013 1 次提交
    • T
      kthread: Prevent unpark race which puts threads on the wrong cpu · f2530dc7
      Thomas Gleixner 提交于
      The smpboot threads rely on the park/unpark mechanism which binds per
      cpu threads on a particular core. Though the functionality is racy:
      
      CPU0	       	 	CPU1  	     	    CPU2
      unpark(T)				    wake_up_process(T)
        clear(SHOULD_PARK)	T runs
      			leave parkme() due to !SHOULD_PARK  
        bind_to(CPU2)		BUG_ON(wrong CPU)						    
      
      We cannot let the tasks move themself to the target CPU as one of
      those tasks is actually the migration thread itself, which requires
      that it starts running on the target cpu right away.
      
      The solution to this problem is to prevent wakeups in park mode which
      are not from unpark(). That way we can guarantee that the association
      of the task to the target cpu is working correctly.
      
      Add a new task state (TASK_PARKED) which prevents other wakeups and
      use this state explicitly for the unpark wakeup.
      
      Peter noticed: Also, since the task state is visible to userspace and
      all the parked tasks are still in the PID space, its a good hint in ps
      and friends that these tasks aren't really there for the moment.
      
      The migration thread has another related issue.
      
      CPU0	      	     	 CPU1
      Bring up CPU2
      create_thread(T)
      park(T)
       wait_for_completion()
      			 parkme()
      			 complete()
      sched_set_stop_task()
      			 schedule(TASK_PARKED)
      
      The sched_set_stop_task() call is issued while the task is on the
      runqueue of CPU1 and that confuses the hell out of the stop_task class
      on that cpu. So we need the same synchronizaion before
      sched_set_stop_task().
      Reported-by: NDave Jones <davej@redhat.com>
      Reported-and-tested-by: NDave Hansen <dave@sr71.net>
      Reported-and-tested-by: NBorislav Petkov <bp@alien8.de>
      Acked-by: NPeter Ziljstra <peterz@infradead.org>
      Cc: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
      Cc: dhillf@gmail.com
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: stable@vger.kernel.org
      Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1304091635430.21884@ionosSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      f2530dc7
  14. 20 3月, 2013 1 次提交
    • T
      sched: replace PF_THREAD_BOUND with PF_NO_SETAFFINITY · 14a40ffc
      Tejun Heo 提交于
      PF_THREAD_BOUND was originally used to mark kernel threads which were
      bound to a specific CPU using kthread_bind() and a task with the flag
      set allows cpus_allowed modifications only to itself.  Workqueue is
      currently abusing it to prevent userland from meddling with
      cpus_allowed of workqueue workers.
      
      What we need is a flag to prevent userland from messing with
      cpus_allowed of certain kernel tasks.  In kernel, anyone can
      (incorrectly) squash the flag, and, for worker-type usages,
      restricting cpus_allowed modification to the task itself doesn't
      provide meaningful extra proection as other tasks can inject work
      items to the task anyway.
      
      This patch replaces PF_THREAD_BOUND with PF_NO_SETAFFINITY.
      sched_setaffinity() checks the flag and return -EINVAL if set.
      set_cpus_allowed_ptr() is no longer affected by the flag.
      
      This will allow simplifying workqueue worker CPU affinity management.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Acked-by: NIngo Molnar <mingo@kernel.org>
      Reviewed-by: NLai Jiangshan <laijs@cn.fujitsu.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      14a40ffc
  15. 13 12月, 2012 1 次提交
  16. 13 10月, 2012 1 次提交
    • A
      infrastructure for saner ret_from_kernel_thread semantics · a74fb73c
      Al Viro 提交于
      * 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: NAl Viro <viro@zeniv.linux.org.uk>
      a74fb73c
  17. 13 8月, 2012 1 次提交
  18. 23 7月, 2012 2 次提交
    • T
      kthread_worker: reimplement flush_kthread_work() to allow freeing the work item being executed · 46f3d976
      Tejun Heo 提交于
      kthread_worker provides minimalistic workqueue-like interface for
      users which need a dedicated worker thread (e.g. for realtime
      priority).  It has basic queue, flush_work, flush_worker operations
      which mostly match the workqueue counterparts; however, due to the way
      flush_work() is implemented, it has a noticeable difference of not
      allowing work items to be freed while being executed.
      
      While the current users of kthread_worker are okay with the current
      behavior, the restriction does impede some valid use cases.  Also,
      removing this difference isn't difficult and actually makes the code
      easier to understand.
      
      This patch reimplements flush_kthread_work() such that it uses a
      flush_work item instead of queue/done sequence numbers.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      46f3d976
    • T
      kthread_worker: reorganize to prepare for flush_kthread_work() reimplementation · 9a2e03d8
      Tejun Heo 提交于
      Make the following two non-functional changes.
      
      * Separate out insert_kthread_work() from queue_kthread_work().
      
      * Relocate struct kthread_flush_work and kthread_flush_work_fn()
        definitions above flush_kthread_work().
      
      v2: Added lockdep_assert_held() in insert_kthread_work() as suggested
          by Andy Walls.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Acked-by: NAndy Walls <awalls@md.metrocast.net>
      9a2e03d8
  19. 24 11月, 2011 1 次提交
    • T
      freezer: kill unused set_freezable_with_signal() · 34b087e4
      Tejun Heo 提交于
      There's no in-kernel user of set_freezable_with_signal() left.  Mixing
      TIF_SIGPENDING with kernel threads can lead to nasty corner cases as
      kernel threads never travel signal delivery path on their own.
      
      e.g. the current implementation is buggy in the cancelation path of
      __thaw_task().  It calls recalc_sigpending_and_wake() in an attempt to
      clear TIF_SIGPENDING but the function never clears it regardless of
      sigpending state.  This means that signallable freezable kthreads may
      continue executing with !freezing() && stuck TIF_SIGPENDING, which can
      be troublesome.
      
      This patch removes set_freezable_with_signal() along with
      PF_FREEZER_NOSIG and recalc_sigpending*() calls in freezer.  User
      tasks get TIF_SIGPENDING, kernel tasks get woken up and the spurious
      sigpending is dealt with in the usual signal delivery path.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Acked-by: NOleg Nesterov <oleg@redhat.com>
      34b087e4
  20. 22 11月, 2011 1 次提交
    • T
      freezer: implement and use kthread_freezable_should_stop() · 8a32c441
      Tejun Heo 提交于
      Writeback and thinkpad_acpi have been using thaw_process() to prevent
      deadlock between the freezer and kthread_stop(); unfortunately, this
      is inherently racy - nothing prevents freezing from happening between
      thaw_process() and kthread_stop().
      
      This patch implements kthread_freezable_should_stop() which enters
      refrigerator if necessary but is guaranteed to return if
      kthread_stop() is invoked.  Both thaw_process() users are converted to
      use the new function.
      
      Note that this deadlock condition exists for many of freezable
      kthreads.  They need to be converted to use the new should_stop or
      freezable workqueue.
      
      Tested with synthetic test case.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Acked-by: NHenrique de Moraes Holschuh <ibm-acpi@hmh.eng.br>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Oleg Nesterov <oleg@redhat.com>
      8a32c441
  21. 31 10月, 2011 1 次提交
  22. 28 5月, 2011 1 次提交
  23. 31 3月, 2011 1 次提交
  24. 23 3月, 2011 1 次提交
  25. 07 1月, 2011 1 次提交
  26. 22 12月, 2010 1 次提交
  27. 23 10月, 2010 1 次提交
  28. 29 6月, 2010 2 次提交
    • T
      kthread: implement kthread_data() · 82805ab7
      Tejun Heo 提交于
      Implement kthread_data() which takes @task pointing to a kthread and
      returns @data specified when creating the kthread.  The caller is
      responsible for ensuring the validity of @task when calling this
      function.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      82805ab7
    • T
      kthread: implement kthread_worker · b56c0d89
      Tejun Heo 提交于
      Implement simple work processor for kthread.  This is to ease using
      kthread.  Single thread workqueue used to be used for things like this
      but workqueue won't guarantee fixed kthread association anymore to
      enable worker sharing.
      
      This can be used in cases where specific kthread association is
      necessary, for example, when it should have RT priority or be assigned
      to certain cgroup.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      b56c0d89
  29. 25 3月, 2010 1 次提交
  30. 09 2月, 2010 2 次提交
  31. 17 12月, 2009 1 次提交
  32. 03 11月, 2009 1 次提交
  33. 09 9月, 2009 1 次提交