1. 29 Dec, 2008 8 commits
  2. 21 Oct, 2008 2 commits
  3. 16 Oct, 2008 1 commit
  4. 26 Jul, 2008 2 commits
  5. 20 Jun, 2008 1 commit
  6. 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>
  7. 22 Apr, 2008 1 commit
  8. 19 Apr, 2008 1 commit
  9. 16 Apr, 2008 1 commit
  10. 07 Apr, 2008 2 commits
  11. 22 Feb, 2008 1 commit
  12. 23 Jan, 2008 1 commit
  13. 18 Dec, 2007 1 commit
  14. 24 Oct, 2007 1 commit
  15. 22 Oct, 2007 1 commit
  16. 31 Jul, 2007 1 commit
  17. 16 Jul, 2007 1 commit
  18. 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
      The modalias format is like this:
      (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>
  19. 17 Feb, 2007 1 commit
  20. 12 Feb, 2007 1 commit
  21. 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:
      > >
      > > Other Kernels Tested and Results:
      > >
      > >     OK
      > >     OK
      > >     OK
      > >     BAD
      > >     BAD 2.6.18-1.2869.fc6
      > >     BAD +
      > >     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>
  22. 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:
      > >             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>
  23. 08 Dec, 2006 1 commit
  24. 15 Nov, 2006 1 commit
  25. 25 Oct, 2006 1 commit
  26. 04 Oct, 2006 1 commit
  27. 09 Jul, 2006 1 commit
  28. 29 Jun, 2006 1 commit
  29. 26 Jun, 2006 1 commit
  30. 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>