linux-stable.git/drivers/ata/libata-core.c, branch linux-5.18.y

ata: libata-core: fix NULL pointer deref in ata_host_alloc_pinfo()

2022-06-22T12:27:50+00:00

[ Upstream commit bf476fe22aa1851bab4728e0c49025a6a0bea307 ]

In an unlikely (and probably wrong?) case that the 'ppi' parameter of
ata_host_alloc_pinfo() points to an array starting with a NULL pointer,
there's going to be a kernel oops as the 'pi' local variable won't get
reassigned from the initial value of NULL. Initialize 'pi' instead to
'&ata_dummy_port_info' to fix the possible kernel oops for good...

Found by Linux Verification Center (linuxtesting.org) with the SVACE static
analysis tool.

Signed-off-by: Sergey Shtylyov 
Signed-off-by: Damien Le Moal 
Signed-off-by: Sasha Levin

libata: fix reading concurrent positioning ranges log

2022-06-14T16:45:17+00:00

commit c745dfc541e78428ba3986f1d17fe1dfdaca8184 upstream.

The concurrent positioning ranges log is not a fixed size and may depend
on how many ranges are supported by the device. This patch uses the size
reported in the GPL directory to determine the number of pages supported
by the device before attempting to read this log page.

This resolves this error from the dmesg output:
    ata6.00: Read log 0x47 page 0x00 failed, Emask 0x1

Cc: stable@vger.kernel.org
Fixes: fe22e1c2f705 ("libata: support concurrent positioning ranges log")
Signed-off-by: Tyler Erickson 
Reviewed-by: Muhammad Ahmad 
Tested-by: Michael English 
Signed-off-by: Damien Le Moal 
Signed-off-by: Greg Kroah-Hartman

ata: libata-core: Disable READ LOG DMA EXT for Samsung 840 EVOs

2022-04-04T00:56:37+00:00

Samsung' 840 EVO with the latest firmware (EXT0DB6Q) locks up with
the a message: "READ LOG DMA EXT failed, trying PIO" during boot.

Initially this was discovered because it caused a crash
with the sata_dwc_460ex controller on a WD MyBook Live DUO.

The reporter "Tice Rex" which has the unique opportunity that he
has two Samsung 840 EVO SSD! One with the older firmware "EXT0BB0Q"
which booted fine and didn't expose "READ LOG DMA EXT". But the
newer/latest firmware "EXT0DB6Q" caused the headaches.

BugLink: https://github.com/openwrt/openwrt/issues/9505
Signed-off-by: Christian Lamparter 
Signed-off-by: Damien Le Moal

Merge tag 'ata-5.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/libata

2022-03-23T21:35:59+00:00

Pull ata updates from Damien Le Moal:
 "For this cycle, no big change but many small fixes and code cleanup to
  libata, the ahci driver and various pata drivers. In more details:

   - Code simplification in pata_platform using
     platform_get_mem_or_io(), from Lad.

   - Fix read-only arrays declarations as const in pata_atiixp and
     pata_pdc202xx_old, from Colin.

   - Various cleanups and code simplification in libata-scsi, from me.

   - Remove dead code in libata-acpi, from Sergey.

   - Skip device scan deboune delay for Marvell 88SE9235 adapters (ahci)
     to speedup boot, from Paul.

   - Simplify functions declaration and use for functions always
     returning 0 in libata-core, from Sergey.

   - Non-fatal error fixes and in the pata_hpt366 and pata_hpt3x2n
     drivers, from Sergey.

   - Various code cleanup in the pata_artop, pata_hpt37x, pata_hpt366,
     pata_hpt3x2n, pata_samsung_cf and sata_rcar drivers, from Sergey.

   - Some libata-sff and libata-scsi code cleanup (e.g. change functions
     to return "bool"), from Sergey.

   - Renae ahci_board_mobile to board_ahci_low_power to be more
     descriptive of the feature as that is also used on PC and server
     AHCI adapters, from Mario.

   - Cleanup of OF match tables, from Geert.

   - Simplify the pata_pxa driver initialization using
     platform_get_irq(), from Minghao"

* tag 'ata-5.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/libata: (38 commits)
  ata: pata_pxa: Use platform_get_irq() to get the interrupt
  ata: Drop commas after OF match table sentinels
  ata: ahci: Rename CONFIG_SATA_LPM_MOBILE_POLICY configuration item
  ata: ahci: Rename `AHCI_HFLAG_IS_MOBILE`
  ata: ahci: Rename board_ahci_mobile
  ata: pata_hpt37x: merge transfer mode setting methods
  ata: libata-sff: use *switch* statement in ata_sff_dev_classify()
  ata: add/use ata_taskfile::{error|status} fields
  ata: Kconfig: fix sata gemini compile test condition
  ata: libata-scsi: use *switch* statements to check SCSI command codes
  ata: libata-sff: refactor ata_sff_altstatus()
  ata: libata-sff: refactor ata_sff_set_devctl()
  ata: libata-sff: make ata_resources_present() return 'bool'
  ata: pata_hpt3x2n: disable fast interrupts in prereset() method
  ata: pata_hpt37x: disable fast interrupts in prereset() method
  ata: pata_hpt366: disable fast interrupts in prereset() method
  ata: pata_mpc52xx: use GFP_KERNEL
  ata: sata_rcar: drop unused #define's
  ata: pata_hpt366: check channel enable bits
  ata: sata_rcar: make sata_rcar_ata_devchk() return 'bool'
  ...

ata: add/use ata_taskfile::{error|status} fields

2022-02-20T00:06:05+00:00

Add the explicit error and status register fields to 'struct ata_taskfile'
using the anonymous *union*s ('struct ide_taskfile' had that for ages!) and
update the libata taskfile code accordingly. There should be no object code
changes resulting from that...

Signed-off-by: Sergey Shtylyov 
Signed-off-by: Damien Le Moal

ata: libata: make ata_host_suspend() void

2022-02-19T02:18:35+00:00

ata_host_suspend() always returns 0, so the result checks in many drivers
look pointless.  Let's make this function return *void* instead of *int*.

Found by Linux Verification Center (linuxtesting.org) with the SVACE static
analysis tool.

Signed-off-by: Sergey Shtylyov 
Acked-by: Uwe Kleine-König 
Reviewed-by: Hannes Reinecke 
Signed-off-by: Damien Le Moal

ata: libata-core: Disable TRIM on M88V29

2022-02-08T08:06:14+00:00

This device is a CF card, or possibly an SSD in CF form factor.
It supports NCQ and high speed DMA.

While it also advertises TRIM support, I/O errors are reported
when the discard mount option fstrim is used. TRIM also fails
when disabling NCQ and not just as an NCQ command.

TRIM must be disabled for this device.

Signed-off-by: Zoltán Böszörményi 
Signed-off-by: Damien Le Moal

ata: libata-core: Fix ata_dev_config_cpr()

2022-02-07T13:38:02+00:00

The concurrent positioning ranges log page 47h is a general purpose log
page and not a subpage of the indentify device log. Using
ata_identify_page_supported() to test for concurrent positioning ranges
support is thus wrong. ata_log_supported() must be used.

Furthermore, unlike other advanced ATA features (e.g. NCQ priority),
accesses to the concurrent positioning ranges log page are not gated by
a feature bit from the device IDENTIFY data. Since many older drives
react badly to the READ LOG EXT and/or READ LOG DMA EXT commands isued
to read device log pages, avoid problems with older drives by limiting
the concurrent positioning ranges support detection to drives
implementing at least the ACS-4 ATA standard (major version 11). This
additional condition effectively turns ata_dev_config_cpr() into a nop
for older drives, avoiding problems in the field.

Fixes: fe22e1c2f705 ("libata: support concurrent positioning ranges log")
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=215519
Cc: stable@vger.kernel.org
Reviewed-by: Hannes Reinecke 
Tested-by: Abderraouf Adjal 
Signed-off-by: Damien Le Moal

ata: libata-core: Introduce ATA_HORKAGE_NO_LOG_DIR horkage

2022-02-04T07:44:23+00:00

06f6c4c6c3e8 ("ata: libata: add missing ata_identify_page_supported() calls")
introduced additional calls to ata_identify_page_supported(), thus also
adding indirectly accesses to the device log directory log page through
ata_log_supported(). Reading this log page causes SATADOM-ML 3ME devices
to lock up.

Introduce the horkage flag ATA_HORKAGE_NO_LOG_DIR to prevent accesses to
the log directory in ata_log_supported() and add a blacklist entry
with this flag for "SATADOM-ML 3ME" devices.

Fixes: 636f6e2af4fb ("libata: add horkage for missing Identify Device log")
Cc: stable@vger.kernel.org # v5.10+
Signed-off-by: Anton Lundin 
Signed-off-by: Damien Le Moal

ata: libata: ata_{sff|std}_prereset() always return 0

2022-02-03T00:04:33+00:00

ata_std_prereset() always returns 0, hence the check in ata_sff_prereset()
is pointless and thus it also can return only 0 (however, we cannot change
the prototypes of ata_{sff|std}_prereset() as they implement the driver's
prereset() method).

Found by Linux Verification Center (linuxtesting.org) with the SVACE static
analysis tool.

Signed-off-by: Sergey Shtylyov 
Signed-off-by: Damien Le Moal