1. 09 Sep, 2005 1 commit
    • Neil Brown's avatar
      [SCSI] fix possible deadlock in scsi_lib.c · 286f3e13
      Neil Brown authored
      
      
        If a filesystem, while writing out data, decides that it is good
      to issue a cache flush on a SCSI drive (or other 'sd' device), it will
      call blkdev_issue_flush which calls ->issue_flush_fn which is
      scsi_issue_flush_fn.
      This calls sd_issue_flush which calls sd_sync_cache, which calls
      scsi_execute_request.
      This will (as sshdr != NULL) call
          kmalloc(SCSI_SENSE_BUFFERSIZE, GFP_KERNEL)
      
      If memory is tight, the presence of GFP_KERNEL may cause write
      requests to be sent to some filesystem to free up memory, however if
      that filesystem is waiting for the issue_flush_fn to complete, you
      could get a deadlock.
      
      I wonder if it might be more appropriate to use GFP_NOIO as in the
      following patch.
      
      I wonder if it might be even more appropriate to cope better with a
      kmalloc failure, especially as in this use, sd_sync_cache only will
      use the sense information to print out a more informative error
      message.
      Signed-off-by: default avatarNeil Brown <neilb@suse.de>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      286f3e13
  2. 06 Sep, 2005 1 commit
    • James Bottomley's avatar
      [SCSI] quieten messages on scsi_execute commands · 3173d8c3
      James Bottomley authored
      
      
      scsi_io_completion() can be a bit noisy about certain conditions.
      Previously this wasn't a problem for internally generated commands,
      since they never hit it.  However, since we do all SCSI commands via
      bios, now they do.  user CD testers like magicdev are now getting not
      ready messages every time they touch the CD to see if there's anything
      in it.
      
      Fix this by making all scsi_execute commands REQ_QUIET and making
      scsi_finish_io() not say anything for REQ_QUIET.
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      3173d8c3
  3. 28 Aug, 2005 8 commits
  4. 30 Jul, 2005 1 commit
  5. 14 Jul, 2005 1 commit
  6. 28 Jun, 2005 1 commit
  7. 26 Jun, 2005 3 commits
  8. 24 Jun, 2005 1 commit
  9. 20 May, 2005 5 commits
  10. 18 Apr, 2005 2 commits
  11. 16 Apr, 2005 4 commits