1. 10 Nov, 2009 5 commits
    • Tejun Heo's avatar
      sata_nv: make sure link is brough up online when skipping hardreset · 76132171
      Tejun Heo authored
      commit 6489e326 upstream.
      
      prereset doesn't bring link online if hardreset is about to happen and
      nv_hardreset() may skip if conditions are not right so softreset may
      be entered with non-working link status if the system firmware didn't
      bring it up before entering OS code which can happen during resume.
      This patch makes nv_hardreset() to bring up the link if it's skipping
      reset.
      
      This bug was reported by frodone@gmail.com in the following bug entry.
      
        http://bugzilla.kernel.org/show_bug.cgi?id=14329Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Reported-by: frodone@gmail.com
      Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      76132171
    • Tejun Heo's avatar
      libata: fix PMP initialization · 32f4683d
      Tejun Heo authored
      commit 4f7c2874 upstream.
      
      Commit 842faa6c fixed error handling
      during attach by not committing detected device class to dev->class
      while attaching a new device.  However, this change missed the PMP
      class check in the configuration loop causing a new PMP device to go
      through ata_dev_configure() as if it were an ATA or ATAPI device.
      
      As PMP device doesn't have a regular IDENTIFY data, this makes
      ata_dev_configure() tries to configure a PMP device using an invalid
      data.  For the most part, it wasn't too harmful and went unnoticed but
      this ends up clearing dev->flags which may have ATA_DFLAG_AN set by
      sata_pmp_attach().  This means that SATA_PMP_FEAT_NOTIFY ends up being
      disabled on PMPs and on PMPs which honor the flag breaks hotplug
      support.
      
      This problem was discovered and reported by Ethan Hsiao.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Reported-by: default avatarEthan Hsiao <ethanhsiao@jmicron.com>
      Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      32f4683d
    • Tejun Heo's avatar
      libata: fix internal command failure handling · 99823646
      Tejun Heo authored
      commit f4b31db9 upstream.
      
      When an internal command fails, it should be failed directly without
      invoking EH.  In the original implemetation, this was accomplished by
      letting internal command bypass failure handling in ata_qc_complete().
      However, later changes added post-successful-completion handling to
      that code path and the success path is no longer adequate as internal
      command failure path.  One of the visible problems is that internal
      command failure due to timeout or other freeze conditions would
      spuriously trigger WARN_ON_ONCE() in the success path.
      
      This patch updates failure path such that internal command failure
      handling is contained there.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      99823646
    • Yinghai Lu's avatar
      pci: increase alignment to make more space for hidden code · 2f37b165
      Yinghai Lu authored
      commit 15b812f1 upstream.
      
      As reported in
      
      	http://bugzilla.kernel.org/show_bug.cgi?id=13940
      
      on some system when acpi are enabled, acpi clears some BAR for some
      devices without reason, and kernel will need to allocate devices for
      them.  It then apparently hits some undocumented resource conflict,
      resulting in non-working devices.
      
      Try to increase alignment to get more safe range for unassigned devices.
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      2f37b165
    • Earl Chew's avatar
      fs: pipe.c null pointer dereference · c40ca2aa
      Earl Chew authored
      commit ad396024 upstream.
      
      This patch fixes a null pointer exception in pipe_rdwr_open() which
      generates the stack trace:
      
      > Unable to handle kernel NULL pointer dereference at 0000000000000028 RIP:
      >  [<ffffffff802899a5>] pipe_rdwr_open+0x35/0x70
      >  [<ffffffff8028125c>] __dentry_open+0x13c/0x230
      >  [<ffffffff8028143d>] do_filp_open+0x2d/0x40
      >  [<ffffffff802814aa>] do_sys_open+0x5a/0x100
      >  [<ffffffff8021faf3>] sysenter_do_call+0x1b/0x67
      
      The failure mode is triggered by an attempt to open an anonymous
      pipe via /proc/pid/fd/* as exemplified by this script:
      
      =============================================================
      while : ; do
         { echo y ; sleep 1 ; } | { while read ; do echo z$REPLY; done ; } &
         PID=$!
         OUT=$(ps -efl | grep 'sleep 1' | grep -v grep |
              { read PID REST ; echo $PID; } )
         OUT="${OUT%% *}"
         DELAY=$((RANDOM * 1000 / 32768))
         usleep $((DELAY * 1000 + RANDOM % 1000 ))
         echo n > /proc/$OUT/fd/1                 # Trigger defect
      done
      =============================================================
      
      Note that the failure window is quite small and I could only
      reliably reproduce the defect by inserting a small delay
      in pipe_rdwr_open(). For example:
      
       static int
       pipe_rdwr_open(struct inode *inode, struct file *filp)
       {
             msleep(100);
             mutex_lock(&inode->i_mutex);
      
      Although the defect was observed in pipe_rdwr_open(), I think it
      makes sense to replicate the change through all the pipe_*_open()
      functions.
      
      The core of the change is to verify that inode->i_pipe has not
      been released before attempting to manipulate it. If inode->i_pipe
      is no longer present, return ENOENT to indicate so.
      
      The comment about potentially using atomic_t for i_pipe->readers
      and i_pipe->writers has also been removed because it is no longer
      relevant in this context. The inode->i_mutex lock must be used so
      that inode->i_pipe can be dealt with correctly.
      Signed-off-by: default avatarEarl Chew <earl_chew@agilent.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      c40ca2aa
  2. 22 Oct, 2009 35 commits