All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "TJ Adams" <tadamsjr@google.com>
Cc: dlemoal@kernel.org, cassel@kernel.org, linux-ide@vger.kernel.org
Subject: Re: [PATCH] ata: libata-core: Allow capacity transition to zero for locked drives
Date: Mon, 22 Jun 2026 18:40:58 +0000	[thread overview]
Message-ID: <20260622184058.EE58B1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260622182844.2795777-1-tadamsjr@google.com>

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

  reply	other threads:[~2026-06-22 18:40 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-22 18:28 [PATCH] ata: libata-core: Allow capacity transition to zero for locked drives TJ Adams
2026-06-22 18:40 ` sashiko-bot [this message]
2026-06-24 14:20 ` Niklas Cassel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260622184058.EE58B1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=cassel@kernel.org \
    --cc=dlemoal@kernel.org \
    --cc=linux-ide@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=tadamsjr@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.