1. 27 Jan, 2007 7 commits
    • 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
    • David C Somayajulu's avatar
      [SCSI] qla4xxx: bug fixes · 477ffb9d
      David C Somayajulu authored
      The included patch fixes the following issues:
      
      1. qla3xxx/qla4xxx co-existence issue which can result in a lockup
      when qla3xxx driver is unloaded, or when ifdown; ifup is performed on
      one of the interfaces correponding to qla3xxx. This is because qla4xxx
      HBA supports one ethernet and iscsi interfaces per port. Both iscsi
      and ethernet interfaces share the same state machine. The problem has
      to do with synchronizing access to the state machine in the event of a
      reset
      
      2. mutex_lock() is sometimes not followed by mutex_unlock() prior to
      invoking a msleep() in qla4xxx_mailbox_command()
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      477ffb9d
    • Matthew Wilcox's avatar
      [SCSI] Fix scsi_add_device() for async scanning · 938e2ac0
      Matthew Wilcox authored
      I had thought that all drivers which didn't call scsi_scan_host()
      called scsi_scan_target().  Some, such as sbp2, mptsas and libata-scsi,
      call scsi_add_device() or __scsi_add_device().  We just need to wait
      for the currently executing async scans to complete first.  This is the
      same code that's in scsi_scan_target(), except that we have to return
      an error instead of void when we're declining to scan at all.
      Signed-off-by: default avatarMatthew Wilcox <matthew@wil.cx>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      938e2ac0
    • Linus Torvalds's avatar
      Merge master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 · 7d620a4e
      Linus Torvalds authored
      * master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6:
        [IPV4]: Fix single-entry /proc/net/fib_trie output.
        [SELINUX]: Fix 2.6.20-rc6 build when no xfrm
      7d620a4e
    • Robert Olsson's avatar
      [IPV4]: Fix single-entry /proc/net/fib_trie output. · 095b8501
      Robert Olsson authored
       
      When main table is just a single leaf this gets printed as belonging to the 
      local table in /proc/net/fib_trie. A fix is below.
      Signed-off-by: default avatarRobert Olsson <robert.olsson@its.uu.se>
      Acked-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      095b8501
    • Venkat Yekkirala's avatar
      [SELINUX]: Fix 2.6.20-rc6 build when no xfrm · 342a0cff
      Venkat Yekkirala authored
      This patch is an incremental fix to the flow_cache_genid
      patch for selinux that breaks the build of 2.6.20-rc6 when
      xfrm is not configured.
      Signed-off-by: default avatarVenkat Yekkirala <vyekkirala@TrustedCS.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      342a0cff
    • David S. Miller's avatar
      [SPARC64]: Set g4/g5 properly in sun4v dtlb-prot handling. · 86d43258
      David S. Miller authored
      Mirror the logic in the sun4u handler, we have to update
      both registers even when we branch out to window fault
      fixup handling.
      
      The way it works is that if we are in etrap processing a
      fault already, g4/g5 holds the original fault information.
      If we take a window spill fault while doing etrap, then
      we put the window spill fault info into g4/g5 and this is
      what the top-level fault handler ends up processing first.
      
      Then we retry the originally faulting instruction, and
      process the original fault at that time.
      
      This is all necessary because of how constrained the trap
      registers are in these code paths.  These cases trigger
      very rarely, so even if there is some performance implication
      it's doesn't happen very often.  In fact the rarity is why
      it took so long to trigger and find this particular bug.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      86d43258
  2. 26 Jan, 2007 33 commits