1. 26 Jul, 2008 2 commits
  2. 20 Jun, 2008 1 commit
  3. 20 May, 2008 1 commit
    • Greg Kroah-Hartman's avatar
      SCSI: fix race in device_create · 24b42566
      Greg Kroah-Hartman authored
      
      
      There is a race from when a device is created with device_create() and
      then the drvdata is set with a call to dev_set_drvdata() in which a
      sysfs file could be open, yet the drvdata will be NULL, causing all
      sorts of bad things to happen.
      
      This patch fixes the problem by using the new function,
      device_create_drvdata().  It fixes the problem in all of the scsi
      drivers that need it.
      
      Cc: Kay Sievers <kay.sievers@vrfy.org>
      Cc: Doug Gilbert <dgilbert@interlog.com>
      Cc: James E.J. Bottomley <James.Bottomley@HansenPartnership.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      24b42566
  4. 22 Apr, 2008 1 commit
  5. 19 Apr, 2008 1 commit
  6. 16 Apr, 2008 1 commit
  7. 07 Apr, 2008 2 commits
  8. 22 Feb, 2008 1 commit
  9. 23 Jan, 2008 1 commit
  10. 18 Dec, 2007 1 commit
  11. 24 Oct, 2007 1 commit
  12. 22 Oct, 2007 1 commit
  13. 31 Jul, 2007 1 commit
  14. 16 Jul, 2007 1 commit
  15. 17 Apr, 2007 1 commit
    • Michael Tokarev's avatar
      [SCSI] modalias for scsi devices · d7b8bcb0
      Michael Tokarev authored
      
      
      The following patch adds support for sysfs/uevent modalias
      attribute for scsi devices (like disks, tapes, cdroms etc),
      based on whatever current sd.c, sr.c, st.c and osst.c drivers
      supports.
      
      The modalias format is like this:
      
       scsi:type-0x04
      
      (for TYPE_WORM, handled by sr.c now).
      
      Several comments.
      
      o This hexadecimal type value is because all TYPE_XXX constants
        in include/scsi/scsi.h are given in hex, but __stringify() will
        not convert them to decimal (so it will NOT be scsi:type-4).
        Since it does not really matter in which format it is, while
        both modalias in module and modalias attribute match each other,
        I descided to go for that 0x%02x format (and added a comment in
        include/scsi/scsi.h to keep them that way), instead of changing
        them all to decimal.
      
      o There was no .uevent routine for SCSI bus.  It might be a good
        idea to add some more ueven environment variables in there.
      
      o osst.c driver handles tapes too, like st.c, but only SOME tapes.
        With this setup, hotplug scripts (or whatever is used by the
        user) will try to load both st and osst modules for all SCSI
        tapes found, because both modules have scsi:type-0x01 alias).
        It is not harmful, but one extra module is no good either.
        It is possible to solve this, by exporting more info in
        modalias attribute, including vendor and device identification
        strings, so that modalias becomes something like
          scsi:type-0x12:vendor-Adaptec LTD:device-OnStream Tape Drive
        and having that, match for all 3 attributes, not only device
        type.  But oh well, vendor and device strings may be large,
        and they do contain spaces and whatnot.
        So I left them for now, awaiting for comments first.
      Signed-off-by: default avatarMichael Tokarev <mjt@tls.msk.ru>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      d7b8bcb0
  16. 17 Feb, 2007 1 commit
  17. 12 Feb, 2007 1 commit
  18. 03 Feb, 2007 1 commit
    • Kai Makisara's avatar
      [SCSI] st: fix Tape dies if wrong block size used, bug 7919 · 9abe16c6
      Kai Makisara authored
      On Thu, 1 Feb 2007, Andrew Morton wrote:
      > On Thu, 1 Feb 2007 15:34:29 -0800
      > bugme-daemon@bugzilla.kernel.org wrote:
      >
      > > http://bugzilla.kernel.org/show_bug.cgi?id=7919
      
      
      > >
      > >            Summary: Tape dies if wrong block size used
      > >     Kernel Version: 2.6.20-rc5
      > >             Status: NEW
      > >           Severity: normal
      > >              Owner: scsi_drivers-other@kernel-bugs.osdl.org
      > >          Submitter: dmartin@sccd.ctc.edu
      > >
      > >
      > > Most recent kernel where this bug did *NOT* occur: 2.6.17.14
      > >
      > > Other Kernels Tested and Results:
      > >
      > >     OK 2.6.15.7
      > >     OK 2.6.16.37
      > >     OK 2.6.17.14
      > >     BAD 2.6.18.6
      > >     BAD 2.6.18-1.2869.fc6
      > >     BAD 2.6.19.2 +
      > >     BAD 2.6.20-rc5
      > >
      > > NOTE: 2.6.18-1.2869.fc6 is a Fedora modified kernel, all others are from kernel.org
      > >
      ...
      > > Steps to reproduce:
      > > Get a Adaptec AHA-2940U/UW/D / AIC-7881U card and a tape drive,
      > > install a recent kernel
      > > set the tape block size - mt setblk 4096
      > > read from or write to tape using wrong block size - tar -b 7 -cvf /dev/tape foo
      > >
      Write does not trigger this bug because the driver refuses in fixed block
      mode writes that are not a multiple of the block size. Read does trigger
      it in my system.
      
      The bug is not associated with any specific HBA. st tries to do direct i/o
      in fixed block mode with reads that are not a multiple of tape block size.
      
      The patch in this message fixes the st problem by switching to using the
      driver buffer up to the next close of the device file in fixed block mode
      if the user asks for a read like this.
      
      I don't know why the bug has surfaced only after 2.6.17 although the st
      problem is old. There may be another bug in the block subsystem and this
      patch works around it. However, the patch fixes a problem in st and in
      this way it is a valid fix.
      
      This patch may also fix the bug 7900.
      
      The patch compiles and is lightly tested.
      Signed-off-by: default avatarKai Makisara <kai.makisara@kolumbus.fi>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      9abe16c6
  19. 27 Jan, 2007 1 commit
    • Kai Makisara's avatar
      [SCSI] st: A MTIOCTOP/MTWEOF within the early warning will cause the file number to be incorrect · 91614c05
      Kai Makisara authored
      On Wed, 24 Jan 2007, Andrew Morton wrote:
      
      > On Mon, 22 Jan 2007 13:07:20 -0800
      > bugme-daemon@bugzilla.kernel.org wrote:
      >
      > > http://bugzilla.kernel.org/show_bug.cgi?id=7864
      > >
      > >            Summary: A MTIOCTOP/MTWEOF within the early warning will cause
      > >                     the file number to be incorrect
      > >     Kernel Version: 2.6.19.2
      > >             Status: NEW
      > >           Severity: low
      > >              Owner: io_scsi@kernel-bugs.osdl.org
      > >          Submitter: ce_reisinger@yahoo.com
      > >
      > >
      > > Write records to a SCSI tape until a write fails with a ENOSPC (you have reached
      > > early warning.
      > > Now perform a:
      > >    struct mtget before, after;
      > >    ioctl(fd, MTIOCGET, &before);
      > >    struct mtop mtop = { MTWEOF, 1 };
      > >    ioctl(fd, MTIOCTOP, &mtop);
      > >    ioctl(fd, MTIOCGET, &after);
      > >
      > > Check the value of mt_fileno in the before and after structures. Notice the
      > > after is 2 greater then the before.
      > >
      > > The problem appears to be in the block of code starting at line 2817 in st.c.
      > > This block is entered because the drive did return a CHECK CONDITION with NO
      > > SENSE and the SENSE_EOM bit set. At lines 2824/5 the fileno is incremented. But
      > > it has already been increased by the number of filemarks requested by the
      > > MTIOCTOP. I believe that the residue count in the sense data should be
      > > subtracted from fileno, not a increment as is done.
      > >
      >
      > Thanks.  Could you please send us a tested patch to fix these things, as
      > per http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt
      
       ?
      >
      The analysis is basically correct and explains the bug. According to the
      SCSI standards, the sense code is NO SENSE or RECOVERED ERROR in case
      writing filemark(s) succeeds. If it fails (partly or completely) the sense
      code is VOLUME OVERFLOW. The patch below is tested to fix the case when
      one filemark is successfully written after the EOM early warning. It
      should also fix the case at real EOM but this has not been tested.
      
      Carl, thanks for reporting the bug and providing the analysis for the fix.
      Signed-off-by: default avatarKai Makisara <kai.makisara@kolumbus.fi>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      91614c05
  20. 08 Dec, 2006 1 commit
  21. 15 Nov, 2006 1 commit
  22. 25 Oct, 2006 1 commit
  23. 04 Oct, 2006 1 commit
  24. 09 Jul, 2006 1 commit
  25. 29 Jun, 2006 1 commit
  26. 26 Jun, 2006 1 commit
  27. 23 Jun, 2006 1 commit
    • Miklos Szeredi's avatar
      [PATCH] vfs: add lock owner argument to flush operation · 75e1fcc0
      Miklos Szeredi authored
      
      
      Pass the POSIX lock owner ID to the flush operation.
      
      This is useful for filesystems which don't want to store any locking state
      in inode->i_flock but want to handle locking/unlocking POSIX locks
      internally.  FUSE is one such filesystem but I think it possible that some
      network filesystems would need this also.
      
      Also add a flag to indicate that a POSIX locking request was generated by
      close(), so filesystems using the above feature won't send an extra locking
      request in this case.
      Signed-off-by: default avatarMiklos Szeredi <miklos@szeredi.hu>
      Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      75e1fcc0
  28. 10 Jun, 2006 1 commit
  29. 21 May, 2006 1 commit
  30. 12 Mar, 2006 1 commit
  31. 27 Feb, 2006 2 commits
  32. 26 Jan, 2006 1 commit
    • brking@us.ibm.com's avatar
      [SCSI] Prevent scsi_execute_async from guessing cdb length · bb1d1073
      brking@us.ibm.com authored
      
      
      When the scsi_execute_async interface was added it ended up reducing
      the flexibility of userspace to send arbitrary scsi commands through
      sg using SG_IO. The SG_IO interface allows userspace to specify the
      CDB length. This is now ignored in scsi_execute_async and it is
      guessed using the COMMAND_SIZE macro, which is not always correct,
      particularly for vendor specific commands. This patch adds a cmd_len
      parameter to the scsi_execute_async interface to allow the caller
      to specify the length of the CDB.
      Signed-off-by: default avatarBrian King <brking@us.ibm.com>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      bb1d1073
  33. 14 Jan, 2006 1 commit
  34. 12 Jan, 2006 1 commit
  35. 15 Dec, 2005 2 commits
    • James Bottomley's avatar
      Fix up SCSI mismerge · 7b16318d
      James Bottomley authored
      I forgot to do a git-update-cache on the merged files ...
      7b16318d
    • Kai Makisara's avatar
      [SCSI] Fix st oops with new scsi_execute infrastructure · 787926b1
      Kai Makisara authored
      
      
      Patch from Kai minus last sg_segs clearing which was merged already.
      
      > > Was there a oops or lockup or any debug output you can send me? I will try
      > > some more large request tests with scsi_debug. You also have to compile your
      > > kernel with SCSI_MAX_PHYS_SEGMENTS == 255 to get larger requests now.
      >
      It was an oops in sgl_unmap_user_pages(). The reason is this:
      
      		/* XXX: just for debug. Remove when PageReserved is removed */
      		BUG_ON(PageReserved(page));
      
      I was using /dev/zero as input and it triggers this. When I used a file as
      input, this did not trigger. Should this BUG_ON be removed?
      
      In the same log I noticed that there was another ->sg_segs inconsistency.
      Also, the field ->last_SRpnt was not reset when scsi_execute_async()
      failed. This caused the error message "Async command already active"
      later and prevented proper close.
      
      While doing the changes, I noticed that the current code (since
      2.6.0-test4) does not set the pages dirty when reading with direct i/o.
      
      All of these st problems (including the one I sent earlier) are fixed in
      the patch at the end of this message. These fixes should probably be
      included already in 2.6.15.
      
      After these fixes, the tape seems to operate as expected. Without other
      changes, the largest block size with sym53c896 SCSI adapter is 384 kB. The
      maximum number of sg segments is set to 96 and clustering is disabled in
      the driver. 96 x 4 kB = 384 kB. OK.
      
      I enabled clustering and set max_sectors to 10000 in the SCSI HBA driver.
      Now the block size limit is 5000 kB as expected.
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      787926b1
  36. 14 Dec, 2005 1 commit
    • Mike Christie's avatar
      [SCSI] convert st to use scsi_execute_async · 8b05b773
      Mike Christie authored
      
      
      convert st to always send scatterlists and kill scsi_request
      usage.
      
      This is the same as last time as it was posted, but with Kai's patches
      merged and we now pass the bytes value to scsi_execute_async.
      
      TODO:
      
      - move DIO code to common place or make block layers usable for ULDs.
      - move buffer allocation code to common place for all ULDs to use. And
      make buffer allocation code handle all queue limits so we can find
      out about problems before calling scsi_execute_async.
      - move indirect (copy_to/from_user) paths commone place or make block
      layers usable for ULDs.
      Signed-off-by: default avatarMike Christie <michaelc@cs.wisc.edu>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      8b05b773