1. 20 7月, 2016 1 次提交
    • T
      libata-scsi: better style in ata_msense_*() · 737bee93
      Tom Yan 提交于
      `changeable` is the "version" of mode page requested by the user.
      It will be less confusing/misleading if we do not check it
      "together" with the setting bits of the drive.
      
      Not to mention that we currently have ata_mselect_*() implemented
      in a way that each of them will serve exclusively a particular bit
      on each page. The old style will hence make the condition look even
      more unnecessarily arcane if the ata_msense_*() is reflecting more
      than one bit.
      Signed-off-by: NTom Yan <tom.ty89@gmail.com>
      Signed-off-by: NTejun Heo <tj@kernel.org>
      737bee93
  2. 15 7月, 2016 4 次提交
  3. 14 7月, 2016 1 次提交
  4. 13 7月, 2016 4 次提交
  5. 12 7月, 2016 3 次提交
  6. 07 7月, 2016 2 次提交
  7. 10 5月, 2016 7 次提交
  8. 14 4月, 2016 1 次提交
  9. 05 4月, 2016 11 次提交
  10. 19 2月, 2016 1 次提交
  11. 11 2月, 2016 1 次提交
    • A
      libata: fix HDIO_GET_32BIT ioctl · 287e6611
      Arnd Bergmann 提交于
      As reported by Soohoon Lee, the HDIO_GET_32BIT ioctl does not
      work correctly in compat mode with libata.
      
      I have investigated the issue further and found multiple problems
      that all appeared with the same commit that originally introduced
      HDIO_GET_32BIT handling in libata back in linux-2.6.8 and presumably
      also linux-2.4, as the code uses "copy_to_user(arg, &val, 1)" to copy
      a 'long' variable containing either 0 or 1 to user space.
      
      The problems with this are:
      
      * On big-endian machines, this will always write a zero because it
        stores the wrong byte into user space.
      
      * In compat mode, the upper three bytes of the variable are updated
        by the compat_hdio_ioctl() function, but they now contain
        uninitialized stack data.
      
      * The hdparm tool calling this ioctl uses a 'static long' variable
        to store the result. This means at least the upper bytes are
        initialized to zero, but calling another ioctl like HDIO_GET_MULTCOUNT
        would fill them with data that remains stale when the low byte
        is overwritten. Fortunately libata doesn't implement any of the
        affected ioctl commands, so this would only happen when we query
        both an IDE and an ATA device in the same command such as
        "hdparm -N -c /dev/hda /dev/sda"
      
      * The libata code for unknown reasons started using ATA_IOC_GET_IO32
        and ATA_IOC_SET_IO32 as aliases for HDIO_GET_32BIT and HDIO_SET_32BIT,
        while the ioctl commands that were added later use the normal
        HDIO_* names. This is harmless but rather confusing.
      
      This addresses all four issues by changing the code to use put_user()
      on an 'unsigned long' variable in HDIO_GET_32BIT, like the IDE subsystem
      does, and by clarifying the names of the ioctl commands.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Reported-by: NSoohoon Lee <Soohoon.Lee@f5.com>
      Tested-by: NSoohoon Lee <Soohoon.Lee@f5.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NTejun Heo <tj@kernel.org>
      287e6611
  12. 10 11月, 2015 1 次提交
  13. 27 10月, 2015 2 次提交
  14. 13 10月, 2015 1 次提交