Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 10 5月, 2016 4 次提交
  3. 05 4月, 2016 11 次提交
  5. 19 2月, 2016 1 次提交
  7. 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
  9. 10 11月, 2015 1 次提交
  11. 27 10月, 2015 2 次提交
  13. 13 10月, 2015 1 次提交
  15. 05 10月, 2015 1 次提交
  17. 01 10月, 2015 1 次提交
    • M
      ata: ahci: find eSATA ports and flag them as removable · 8a3e33cf
      由 Manuel Lauss 提交于 
      If the AHCI ports' HPCP or ESP bits are set, the port
should be considered external (e.g. eSATA) and is marked
as removable.  Userspace tools like udisks then treat it
like an usb drive.

With this patch applied, when I plug a drive into the esata port,
KDE pops up a window asking what to do with the drives(s), just
like it does for any random USB stick.

Removability is indicated to the upper layers by way of the
SCSI RMB bit, as I haven't found another way to signal
userspace to treat a sata disk like any usb stick.
Signed-off-by: NManuel Lauss <manuel.lauss@gmail.com>
Signed-off-by: NTejun Heo <tj@kernel.org>
      8a3e33cf
  19. 04 8月, 2015 1 次提交
    • T
      Revert "libata: Implement NCQ autosense" · 74a80d67
      由 Tejun Heo 提交于 
      This reverts commit 42b966fb.

As implemented, ACS-4 sense reporting for ATA devices bypasses error
diagnosis and handling in libata degrading EH behavior significantly.
Revert the related changes for now.
Signed-off-by: NTejun Heo <tj@kernel.org>
Cc: Hannes Reinecke <hare@suse.de>
Cc: stable@vger.kernel.org #v4.1+
      74a80d67
  21. 03 8月, 2015 1 次提交
  23. 24 7月, 2015 1 次提交
  25. 15 7月, 2015 1 次提交
  27. 27 3月, 2015 5 次提交
  29. 25 3月, 2015 1 次提交
    • T
      libata: remove ATA_FLAG_LOWTAG · 3a028243
      由 Tejun Heo 提交于 
      sata_sil24 for some reason pukes when tags are allocated round-robin
which helps tag ordered controllers.  To work around the issue,
72dd299d ("libata: allow sata_sil24 to opt-out of tag ordered
submission") introduced ATA_FLAG_LOWTAG which tells libata tag
allocation to do lowest-first.

However, with the recent switch to blk-mq tag allocation, the liata
tag allocation code path is no longer used and the workaround is now
implemented in the block layer and selected by setting
scsi_host_template->tag_alloc_policy to BLK_TAG_ALLOC_FIFO.  See
9269e234 ("libata: make sata_sil24 use fifo tag allocator").

This leaves ATA_FLAG_LOWTAG withoout any actual user.  Remove it.
Signed-off-by: NTejun Heo <tj@kernel.org>
Cc: Shaohua Li <shli@fb.com>
Cc: Dan Williams <dan.j.williams@intel.com>
      3a028243
  31. 25 1月, 2015 1 次提交
  33. 24 1月, 2015 1 次提交
    • S
      libata: use blk taging · 12cb5ce1
      由 Shaohua Li 提交于 
      libata uses its own tag management which is duplication and the
implementation is poor. And if we switch to blk-mq, tag is build-in.
It's time to switch to generic taging.

The SAS driver has its own tag management, and looks we can't directly
map the host controler tag to SATA tag. So I just bypassed the SAS case.

I changed the code/variable name for the tag management of libata to
make it self contained. Only sas will use it. Later if libsas implements
its tag management, the tag management code in libata can be deleted
easily.

Cc: Jens Axboe <axboe@fb.com>
Cc: Christoph Hellwig <hch@infradead.org>
Signed-off-by: NShaohua Li <shli@fb.com>
Acked-by: NTejun Heo <tj@kernel.org>
Signed-off-by: NJens Axboe <axboe@fb.com>
      12cb5ce1
  35. 08 1月, 2015 1 次提交
    • M
      libata: Whitelist SSDs that are known to properly return zeroes after TRIM · e61f7d1c
      由 Martin K. Petersen 提交于 
      As defined, the DRAT (Deterministic Read After Trim) and RZAT (Return
Zero After Trim) flags in the ATA Command Set are unreliable in the
sense that they only define what happens if the device successfully
executed the DSM TRIM command. TRIM is only advisory, however, and the
device is free to silently ignore all or parts of the request.

In practice this renders the DRAT and RZAT flags completely useless and
because the results are unpredictable we decided to disable discard in
MD for 3.18 to avoid the risk of data corruption.

Hardware vendors in the real world obviously need better guarantees than
what the standards bodies provide. Unfortuntely those guarantees are
encoded in product requirements documents rather than somewhere we can
key off of them programatically. So we are compelled to disabling
discard_zeroes_data for all devices unless we explicitly have data to
support whitelisting them.

This patch whitelists SSDs from a few of the main vendors. None of the
whitelists are based on written guarantees. They are purely based on
empirical evidence collected from internal and external users that have
tested or qualified these drives in RAID deployments.

The whitelist is only meant as a starting point and is by no means
comprehensive:

   - All intel SSD models except for 510
   - Micron M5?0/M600
   - Samsung SSDs
   - Seagate SSDs
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
Reviewed-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NTejun Heo <tj@kernel.org>
      e61f7d1c
  37. 26 12月, 2014 1 次提交
  39. 05 12月, 2014 1 次提交
  41. 25 11月, 2014 1 次提交
  43. 24 11月, 2014 1 次提交