1. 22 11月, 2011 3 次提交
    • 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
    • T
      freezer: unexport refrigerator() and update try_to_freeze() slightly · a0acae0e
      Tejun Heo 提交于
      There is no reason to export two functions for entering the
      refrigerator.  Calling refrigerator() instead of try_to_freeze()
      doesn't save anything noticeable or removes any race condition.
      
      * Rename refrigerator() to __refrigerator() and make it return bool
        indicating whether it scheduled out for freezing.
      
      * Update try_to_freeze() to return bool and relay the return value of
        __refrigerator() if freezing().
      
      * Convert all refrigerator() users to try_to_freeze().
      
      * Update documentation accordingly.
      
      * While at it, add might_sleep() to try_to_freeze().
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Samuel Ortiz <samuel@sortiz.org>
      Cc: Chris Mason <chris.mason@oracle.com>
      Cc: "Theodore Ts'o" <tytso@mit.edu>
      Cc: Steven Whitehouse <swhiteho@redhat.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Jan Kara <jack@suse.cz>
      Cc: KONISHI Ryusuke <konishi.ryusuke@lab.ntt.co.jp>
      Cc: Christoph Hellwig <hch@infradead.org>
      a0acae0e
    • T
      freezer: don't unnecessarily set PF_NOFREEZE explicitly · 3a7cbd50
      Tejun Heo 提交于
      Some drivers set PF_NOFREEZE in their kthread functions which is
      completely unnecessary and racy - some part of freezer code doesn't
      consider cases where PF_NOFREEZE is set asynchronous to freezer
      operations.
      
      In general, there's no reason to allow setting PF_NOFREEZE explicitly.
      Remove them and change the documentation to note that setting
      PF_NOFREEZE directly isn't allowed.
      
      -v2: Dropped change to twl4030-irq.c as it no longer uses PF_NOFREEZE.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Acked-by: N"Gustavo F. Padovan" <padovan@profusion.mobi>
      Acked-by: NSamuel Ortiz <sameo@linux.intel.com>
      Cc: Marcel Holtmann <marcel@holtmann.org>
      Cc: wwang <wei_wang@realsil.com.cn>
      3a7cbd50
  2. 18 11月, 2011 5 次提交
  3. 17 11月, 2011 30 次提交
  4. 16 11月, 2011 2 次提交
    • D
      paride: fix potential information leak in pg_read() · a2c2a0e6
      Dan Carpenter 提交于
      Smatch has a new check for Rosenberg type information leaks where structs
      are copied to the user with uninitialized stack data in them.  i In this
      case, the pg_write_hdr struct has a hole in it.
      
      struct pg_write_hdr {
              char                       magic;                /*     0     1 */
              char                       func;                 /*     1     1 */
              /* XXX 2 bytes hole, try to pack */
              int                        dlen;                 /*     4     4 */
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Cc: Tim Waugh <tim@cyberelk.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      a2c2a0e6
    • S
      cciss: auto engage SCSI mid layer at driver load time · 0007a4c9
      Stephen M. Cameron 提交于
      A long time ago, probably in 2002, one of the distros, or maybe more than
      one, loaded block drivers prior to loading the SCSI mid layer.  This meant
      that the cciss driver, being a block driver, could not engage the SCSI mid
      layer at init time without panicking, and relied on being poked by a
      userland program after the system was up (and the SCSI mid layer was
      therefore present) to engage the SCSI mid layer.
      
      This is no longer the case, and cciss can safely rely on the SCSI mid
      layer being present at init time and engage the SCSI mid layer straight
      away.  This means that users will see their tape drives and medium
      changers at driver load time without need for a script in /etc/rc.d that
      does this:
      
      for x in /proc/driver/cciss/cciss*
      do
      	echo "engage scsi" > $x
      done
      
      However, if no tape drives or medium changers are detected, the SCSI mid
      layer will not be engaged.  If a tape drive or medium change is later
      hot-added to the system it will then be necessary to use the above script
      or similar for the device(s) to be acceesible.
      Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      0007a4c9