All of lore.kernel.org
 help / color / mirror / Atom feed
From: Niklas Cassel <cassel@kernel.org>
To: TJ Adams <tadamsjr@google.com>
Cc: Damien Le Moal <dlemoal@kernel.org>,
	Hannes Reinecke <hare@suse.de>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org,
	Igor Pylypiv <ipylypiv@google.com>,
	Salomon Dushimirimana <salomondush@google.com>
Subject: Re: [PATCH] ata: libata-core: Allow capacity transition to zero for locked drives
Date: Thu, 2 Jul 2026 17:43:57 +0200	[thread overview]
Message-ID: <akaHPScetfl1VbF8@ryzen> (raw)
In-Reply-To: <CAL54JgfakNzRSe8QosjAdBtQnDpiJqjOYFZvuOPjM1RphKEw4A@mail.gmail.com>

Hello TJ,

On Wed, Jul 01, 2026 at 04:16:49PM -0700, TJ Adams wrote:
> On Wed, Jun 24, 2026 at 7:21 AM Niklas Cassel <cassel@kernel.org> wrote:
> >
> > On Mon, Jun 22, 2026 at 11:28:44AM -0700, TJ Adams wrote:
> > > 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.
> 
> 
> Hey Niklas,
> 
> Sorry for the delay in response. I had some difficulty recreating the
> issue outside of our specific test suite.
> 
> > Please explain how you reproduce this.
> > As far as I can see the local n_sectors variable will be 0,
> > and the function call to ata_dev_configure() will set dev->n_sectors
> > to 0, so this should, AFAICT, never get a "n_sectors mismatch" print.
> 
> Here are the steps to recreate it:
> 
> ```bash
> TARGET_DEV="/dev/sdy"
> TARGET_NAME="sdy"
> 
> # Lock Device
> hdparm --user-master u --security-set-pass TempPassword "$TARGET_DEV"
> 
> # Disable SSP
> sg_raw "$TARGET_DEV" 85 06 00 00 90 00 06 00 00 00 00 00 00 00 ef 00
> 
> # In another terminal set active I/O
> dd if="$TARGET_DEV" of=/dev/null bs=1M status=progress
> 
> # Do an active reset (then wait for scsi eh)
> echo 1 > /sys/class/sas_phy/phy-X:Y/hard_reset
> 
> # You can end the dd command in the other terminal and then run this:
> # You should see it fail immediately
> dd if="$TARGET_DEV" of=/dev/null bs=512 count=1
> ```
> 
> Some things to note:
> - Disabling SSP. I had some attempts to recreate the bug but didn't
>   realize SSP was enabled. I would lock the drive but on reset the
>   drive would actually come back up unlocked, masking the bug.
> - The active I/O. This is so there are I/Os in flight whenever the
>   drive gets reset. They should timeout and then trigger the error
>   handling path which will cause the ata device revalidation. Without
>   it the revalidation might not occur and you might not see the bug.
>   I also experienced this.
> 
> > Since you seem to state that the old capacity (local variable n_sectors)
> > is > 0, it seems like the device wasn't locked during the initial boot /
> > ata_dev_configure() call.
> 
> Yeah that's correct. To recreate the issue you should boot unlocked but
> lock at runtime.
> 
> Also here is a dmesg snippet showing the capacity mismatch:
> 
> ```dmesg
>   [76834.784699] ata36.00: status: { DRDY }
>   [76834.784708] ata36: hard resetting link
>   [76834.940530] ata36.00: supports DRM functions and may not be fully
> accessible
>   [76834.940537] ata36.00: Security locked, setting capacity to zero
>   [76834.943566] ata36.00: n_sectors mismatch 15628053168 != 0
> ```
> 
> Let me know if I didn't explain something well or if something is
> missing. Thank you!

Ok, thank you for the information.


Perhaps mention more clearly in the commit message that this happens
when doing a reset of the PHY for a controller that has I/Os in flight.


I think a simpler patch would be:

@@ -3959,7 +3959,7 @@ 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 || ata_id_is_locked(dev->id))
                return 0;
 
        /* n_sectors has changed */


I don't see why we need the additional dev->n_sectors == 0.
If the drive is locked, no need to contiunue, just return.

Perhaps you could test that change instead?


Also, I think we should have a patch 1/2 (or 2/2) that does:


@@ -1338,7 +1338,7 @@ static int ata_hpa_resize(struct ata_device *dev)
        /* do we need to do it? */
        if ((dev->class != ATA_DEV_ATA && dev->class != ATA_DEV_ZAC) ||
            !ata_id_has_lba(dev->id) || !ata_id_hpa_enabled(dev->id) ||
-           (dev->quirks & ATA_QUIRK_BROKEN_HPA))
+           (dev->quirks & ATA_QUIRK_BROKEN_HPA) || ata_id_is_locked(dev->id))
                return 0;
 
        /* read native max address */


To fix the problem Sashiko complained about.


Kind regards,
Niklas

  reply	other threads:[~2026-07-02 15:44 UTC|newest]

Thread overview: 9+ 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
2026-06-24 14:20 ` Niklas Cassel
2026-07-01 23:16   ` TJ Adams
2026-07-02 15:43     ` Niklas Cassel [this message]
2026-07-06 21:00       ` [PATCH v2 0/2] Fixes for security " TJ Adams
2026-07-06 21:00         ` [PATCH v2 1/2] ata: libata-core: Skip HPA resize for " TJ Adams
2026-07-07  6:02           ` Damien Le Moal
2026-07-06 21:00         ` [PATCH v2 2/2] ata: libata-core: Allow capacity transition to zero " TJ Adams

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=akaHPScetfl1VbF8@ryzen \
    --to=cassel@kernel.org \
    --cc=dlemoal@kernel.org \
    --cc=hare@suse.de \
    --cc=ipylypiv@google.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=salomondush@google.com \
    --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.