1. 11 8月, 2008 1 次提交
  2. 26 7月, 2008 8 次提交
  3. 25 7月, 2008 1 次提交
  4. 05 7月, 2008 1 次提交
  5. 24 5月, 2008 1 次提交
  6. 01 5月, 2008 1 次提交
  7. 30 4月, 2008 1 次提交
  8. 29 4月, 2008 2 次提交
  9. 17 4月, 2008 1 次提交
  10. 09 2月, 2008 2 次提交
  11. 26 1月, 2008 1 次提交
  12. 16 1月, 2008 1 次提交
    • J
      lockdep: fix workqueue creation API lockdep interaction · eb13ba87
      Johannes Berg 提交于
      Dave Young reported warnings from lockdep that the workqueue API
      can sometimes try to register lockdep classes with the same key
      but different names. This is not permitted in lockdep.
      
      Unfortunately, I was unaware of that restriction when I wrote
      the code to debug workqueue problems with lockdep and used the
      workqueue name as the lockdep class name. This can obviously
      lead to the problem if the workqueue name is dynamic.
      
      This patch solves the problem by always using a constant name
      for the workqueue's lockdep class, namely either the constant
      name that was passed in or a string consisting of the variable
      name.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      eb13ba87
  13. 20 10月, 2007 2 次提交
  14. 28 8月, 2007 1 次提交
  15. 18 7月, 2007 2 次提交
    • O
      destroy_workqueue() can livelock · 13c22168
      Oleg Nesterov 提交于
      Pointed out by Michal Schmidt <mschmidt@redhat.com>.
      
      The bug was introduced in 2.6.22 by me.
      
      cleanup_workqueue_thread() does flush_cpu_workqueue(cwq) in a loop until
      ->worklist becomes empty.  This is live-lockable, a re-niced caller can get
      CPU after wake_up() and insert a new barrier before the lower-priority
      cwq->thread has a chance to clear ->current_work.
      
      Change cleanup_workqueue_thread() to do flush_cpu_workqueue(cwq) only once.
       We can rely on the fact that run_workqueue() won't return until it flushes
      all works.  So it is safe to call kthread_stop() after that, the "should
      stop" request won't be noticed until run_workqueue() returns.
      Signed-off-by: NOleg Nesterov <oleg@tv-sign.ru>
      Cc: Michal Schmidt <mschmidt@redhat.com>
      Cc: Srivatsa Vaddagiri <vatsa@in.ibm.com>
      Cc: <stable@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      13c22168
    • R
      Freezer: make kernel threads nonfreezable by default · 83144186
      Rafael J. Wysocki 提交于
      Currently, the freezer treats all tasks as freezable, except for the kernel
      threads that explicitly set the PF_NOFREEZE flag for themselves.  This
      approach is problematic, since it requires every kernel thread to either
      set PF_NOFREEZE explicitly, or call try_to_freeze(), even if it doesn't
      care for the freezing of tasks at all.
      
      It seems better to only require the kernel threads that want to or need to
      be frozen to use some freezer-related code and to remove any
      freezer-related code from the other (nonfreezable) kernel threads, which is
      done in this patch.
      
      The patch causes all kernel threads to be nonfreezable by default (ie.  to
      have PF_NOFREEZE set by default) and introduces the set_freezable()
      function that should be called by the freezable kernel threads in order to
      unset PF_NOFREEZE.  It also makes all of the currently freezable kernel
      threads call set_freezable(), so it shouldn't cause any (intentional)
      change of behaviour to appear.  Additionally, it updates documentation to
      describe the freezing of tasks more accurately.
      
      [akpm@linux-foundation.org: build fixes]
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NNigel Cunningham <nigel@nigel.suspend2.net>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: Oleg Nesterov <oleg@tv-sign.ru>
      Cc: Gautham R Shenoy <ego@in.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      83144186
  16. 17 7月, 2007 2 次提交
  17. 24 5月, 2007 1 次提交
    • O
      simplify cleanup_workqueue_thread() · 14441960
      Oleg Nesterov 提交于
      cleanup_workqueue_thread() and cwq_should_stop() are overcomplicated.
      
      Convert the code to use kthread_should_stop/kthread_stop as was
      suggested by Gautham and Srivatsa.
      
      In particular this patch removes the (unlikely) busy-wait loop from the
      exit path, it was a temporary and ugly kludge (if not a bug).
      
      Note: the current code was designed to solve another old problem:
      work->func can't share locks with hotplug callbacks.  I think this could
      be done, see
      
      	http://marc.info/?l=linux-kernel&m=116905366428633
      
      but this needs some more complications to preserve CPU affinity of
      cwq->thread during cpu_up().  A freezer-based hotplug looks more
      appealing.
      
      [akpm@linux-foundation.org: make it more tolerant of gcc borkenness]
      Signed-off-by: NOleg Nesterov <oleg@tv-sign.ru>
      Cc: Zilvinas Valinskas <zilvinas@wilibox.com>
      Cc: Gautham R Shenoy <ego@in.ibm.com>
      Cc: Srivatsa Vaddagiri <vatsa@in.ibm.com>
      Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      14441960
  18. 10 5月, 2007 11 次提交