1. 04 Jan, 2020 5 commits
    • Chao Yu's avatar
      f2fs: fix to update time in lazytime mode · 7a370ecb
      Chao Yu authored
      [ Upstream commit fe1897ea ]
      
      generic/018 reports an inconsistent status of atime, the
      testcase is as below:
      - open file with O_SYNC
      - write file to construct fraged space
      - calc md5 of file
      - record {a,c,m}time
      - defrag file --- do nothing
      - umount & mount
      - check {a,c,m}time
      
      The root cause is, as f2fs enables lazytime by default, atime
      update will dirty vfs inode, rather than dirtying f2fs inode (by set
      with FI_DIRTY_INODE), so later f2fs_write_inode() called from VFS will
      fail to update inode page due to our skip:
      
      f2fs_write_inode()
      	if (is_inode_flag_set(inode, FI_DIRTY_INODE))
      		return 0;
      
      So eventually, after evict(), we lose last atime for ever.
      
      To fix this issue, we need to check whether {a,c,m,cr}time is
      consistent in between inode cache and inode page, and only skip
      f2fs_update_inode() if f2fs inode is not dirty and time is
      consistent as well.
      Signed-off-by: default avatarChao Yu <yuchao0@huawei.com>
      Signed-off-by: default avatarJaegeuk Kim <jaegeuk@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      7a370ecb
    • Evan Green's avatar
      Input: atmel_mxt_ts - disable IRQ across suspend · f6123db9
      Evan Green authored
      [ Upstream commit 463fa44e ]
      
      Across suspend and resume, we are seeing error messages like the following:
      
      atmel_mxt_ts i2c-PRP0001:00: __mxt_read_reg: i2c transfer failed (-121)
      atmel_mxt_ts i2c-PRP0001:00: Failed to read T44 and T5 (-121)
      
      This occurs because the driver leaves its IRQ enabled. Upon resume, there
      is an IRQ pending, but the interrupt is serviced before both the driver and
      the underlying I2C bus have been resumed. This causes EREMOTEIO errors.
      
      Disable the IRQ in suspend, and re-enable it on resume. If there are cases
      where the driver enters suspend with interrupts disabled, that's a bug we
      should fix separately.
      Signed-off-by: default avatarEvan Green <evgreen@chromium.org>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      f6123db9
    • James Smart's avatar
      scsi: lpfc: Fix locking on mailbox command completion · c89e1186
      James Smart authored
      [ Upstream commit 07b85824 ]
      
      Symptoms were seen of the driver not having valid data for mailbox
      commands. After debugging, the following sequence was found:
      
      The driver maintains a port-wide pointer of the mailbox command that is
      currently in execution. Once finished, the port-wide pointer is cleared
      (done in lpfc_sli4_mq_release()). The next mailbox command issued will set
      the next pointer and so on.
      
      The mailbox response data is only copied if there is a valid port-wide
      pointer.
      
      In the failing case, it was seen that a new mailbox command was being
      attempted in parallel with the completion.  The parallel path was seeing
      the mailbox no long in use (flag check under lock) and thus set the port
      pointer.  The completion path had cleared the active flag under lock, but
      had not touched the port pointer.  The port pointer is cleared after the
      lock is released. In this case, the completion path cleared the just-set
      value by the parallel path.
      
      Fix by making the calls that clear mbox state/port pointer while under
      lock.  Also slightly cleaned up the error path.
      
      Link: https://lore.kernel.org/r/20190922035906.10977-8-jsmart2021@gmail.comSigned-off-by: default avatarDick Kennedy <dick.kennedy@broadcom.com>
      Signed-off-by: default avatarJames Smart <jsmart2021@gmail.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      c89e1186
    • Sreekanth Reddy's avatar
      scsi: mpt3sas: Fix clear pending bit in ioctl status · 8770146e
      Sreekanth Reddy authored
      [ Upstream commit 782b2818 ]
      
      When user issues diag register command from application with required size,
      and if driver unable to allocate the memory, then it will fail the register
      command. While failing the register command, driver is not currently
      clearing MPT3_CMD_PENDING bit in ctl_cmds.status variable which was set
      before trying to allocate the memory. As this bit is set, subsequent
      register command will be failed with BUSY status even when user wants to
      register the trace buffer will less memory.
      
      Clear MPT3_CMD_PENDING bit in ctl_cmds.status before returning the diag
      register command with no memory status.
      
      Link: https://lore.kernel.org/r/1568379890-18347-4-git-send-email-sreekanth.reddy@broadcom.comSigned-off-by: default avatarSreekanth Reddy <sreekanth.reddy@broadcom.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      8770146e
    • James Smart's avatar
      scsi: lpfc: Fix discovery failures when target device connectivity bounces · d097dd7d
      James Smart authored
      [ Upstream commit 3f97aed6 ]
      
      An issue was seen discovering all SCSI Luns when a target device undergoes
      link bounce.
      
      The driver currently does not qualify the FC4 support on the target.
      Therefore it will send a SCSI PRLI and an NVMe PRLI. The expectation is
      that the target will reject the PRLI if it is not supported. If a PRLI
      times out, the driver will retry. The driver will not proceed with the
      device until both SCSI and NVMe PRLIs are resolved.  In the failure case,
      the device is FCP only and does not respond to the NVMe PRLI, thus
      initiating the wait/retry loop in the driver.  During that time, a RSCN is
      received (device bounced) causing the driver to issue a GID_FT.  The GID_FT
      response comes back before the PRLI mess is resolved and it prematurely
      cancels the PRLI retry logic and leaves the device in a STE_PRLI_ISSUE
      state. Discovery with the target never completes or resets.
      
      Fix by resetting the node state back to STE_NPR_NODE when GID_FT completes,
      thereby restarting the discovery process for the node.
      
      Link: https://lore.kernel.org/r/20190922035906.10977-10-jsmart2021@gmail.comSigned-off-by: default avatarDick Kennedy <dick.kennedy@broadcom.com>
      Signed-off-by: default avatarJames Smart <jsmart2021@gmail.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      d097dd7d
  2. 31 Dec, 2019 35 commits