[PATCH] ata: libata-core: Allow capacity transition to zero for locked drives

[PATCH] ata: libata-core: Allow capacity transition to zero for locked drives

[TJ Adams]

Commit 91842ed844a0 ("ata: libata-core: Set capacity to zero for a
security locked drive") introduced setting the device capacity (n_sectors)
to zero in ata_dev_configure() if the drive is security locked.

However, during runtime revalidation, ata_dev_revalidate() compares the
new capacity (now 0) with the old capacity (>0) and detects a mismatch.
Since it does not consider the locked status, it returns -ENODEV.

This revalidation failure during Error Handling (EH) causes libata to
eventually disable the device, offlining the SCSI device and resulting
in subsequent accesses returning -ENXIO (No such device or address).

Fix this by allowing the capacity transition to
zero in ata_dev_revalidate() if the drive is reported as security locked by
ata_id_is_locked().

Fixes: 91842ed844a0 ("ata: libata-core: Set capacity to zero for a security locked drive")
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Terrence Adams <tadamsjr@google.com>
---
 drivers/ata/libata-core.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 3b6243f0f91e..d090667979ca 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -3974,7 +3974,8 @@ int ata_dev_revalidate(struct ata_device *dev, unsigned int new_class,
 
 	/* verify n_sectors hasn't changed */
 	if (dev->class != ATA_DEV_ATA || !n_sectors ||
-	    dev->n_sectors == n_sectors)
+	    dev->n_sectors == n_sectors ||
+	    (dev->n_sectors == 0 && ata_id_is_locked(dev->id)))
 		return 0;
 
 	/* n_sectors has changed */
-- 
2.55.0.rc0.786.g65d90a0328-goog

Re: [PATCH] ata: libata-core: Allow capacity transition to zero for locked drives

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] HPA resizing is permanently disabled (quirked) when a drive is initialized or revalidated while security-locked.
--

commit 2df5e6f4cdff68089316d7932aeee91f9d6633ae
Author: TJ Adams <tadamsjr@google.com>
ata: libata-core: Allow capacity transition to zero for locked drives

This commit fixes a revalidation failure that occurs when a security-locked
drive transitions its capacity to zero during Error Handling. It allows this
transition in ata_dev_revalidate() if the drive is reported as locked.

> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
> index e76d15411e2ae..4241a71d1b5d1 100644
> --- a/drivers/ata/libata-core.c
> +++ b/drivers/ata/libata-core.c
> @@ -3959,7 +3959,8 @@ int ata_dev_revalidate(struct ata_device *dev, unsigned int new_class,
>  
>  	/* verify n_sectors hasn't changed */
>  	if (dev->class != ATA_DEV_ATA || !n_sectors ||
> -	    dev->n_sectors == n_sectors)
> +	    dev->n_sectors == n_sectors ||
> +	    (dev->n_sectors == 0 && ata_id_is_locked(dev->id)))

[Severity: High]
This is a pre-existing issue, but since this patch deals with revalidating
locked drives, is there a risk that ata_hpa_resize() permanently disables
HPA resizing for these drives?

Earlier in ata_dev_revalidate(), ata_dev_configure() is called, which then
calls ata_hpa_resize(). If the drive is locked, the command to read the
native max address fails with -EACCES, causing a sticky quirk to be set:

drivers/ata/libata-core.c:ata_hpa_resize() {
        ...
        rc = ata_read_native_max_address(dev, &native_sectors);
        if (rc) {
                ...
                } else if (rc == -EACCES || rc == -EPERM) {
                        ata_dev_warn(dev, "HPA support seems broken ...\n");
                        dev->quirks |= ATA_QUIRK_BROKEN_HPA;
                        return 0;
                }
        ...
}

Because the ATA_QUIRK_BROKEN_HPA quirk is sticky on the device, subsequent
revalidations after the drive is unlocked will silently bypass HPA checks:

drivers/ata/libata-core.c:ata_hpa_resize() {
        if (... || (dev->quirks & ATA_QUIRK_BROKEN_HPA))
                return 0;
        ...
}

Does this functionally prevent the unlocked drive from ever exposing its
full native capacity without a reboot or device removal?

>  		return 0;
>  
>  	/* n_sectors has changed */

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260622182844.2795777-1-tadamsjr@google.com?part=1