Currently, the NVMe driver sets max_hw_wzeroes_unmap_sectors to indicate the
support for unmap Write Zeroes based strictly on the Deallocate Logical Block
Features (dlfeat) in the Identify Namespace data (commit 545fb46e5bc6 "nvme: set
max_hw_wzeroes_unmap_sectors if device supports DEAC bit").

However, certain devices already use the NVME_QUIRK_DEALLOCATE_ZEROES quirk to
indicate that they deterministically return zeroes after a deallocate/discard
operation to support the Write Zeroes operation in nvme_setup_write_zeroes().
For these devices, it is appropriate to treat them as supporting the unmap Write
Zeroes operation.

Update nvme_update_disk_info() to allow the presence of the DEALLOCATE_ZEROES
quirk (combined with DSM support) to set max_hw_wzeroes_unmap_sectors to enable
the support for unmap Write Zeroes. This ensures consistency with how these
devices are handled elsewhere in the driver.

Signed-off-by: Robert Pang <robertpang@google.com>
Link: https://lore.kernel.org/linux-ext4/20260225000531.3658802-1-robertpang@google.com/T/#m5e776f78ecb7631372d82a5cb3d11f8f1f8afe06
---
 drivers/nvme/host/core.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index f5ebcaa2f859..3f5dd3f867e9 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -2120,9 +2120,10 @@ static bool nvme_update_disk_info(struct nvme_ns *ns, struct nvme_id_ns *id,
 	lim->io_min = phys_bs;
 	lim->io_opt = io_opt;
 	if ((ns->ctrl->quirks & NVME_QUIRK_DEALLOCATE_ZEROES) &&
-	    (ns->ctrl->oncs & NVME_CTRL_ONCS_DSM))
+	    (ns->ctrl->oncs & NVME_CTRL_ONCS_DSM)) {
 		lim->max_write_zeroes_sectors = UINT_MAX;
-	else
+		lim->max_hw_wzeroes_unmap_sectors = UINT_MAX;
+	} else
 		lim->max_write_zeroes_sectors = ns->ctrl->max_zeroes_sectors;
 	return valid;
 }
-- 
2.53.0.473.g4a7958ca14-goog

On Thu, Mar 05, 2026 at 12:27:32PM -0800, Robert Pang wrote:
> However, certain devices already use the NVME_QUIRK_DEALLOCATE_ZEROES quirk to
> indicate that they deterministically return zeroes after a deallocate/discard

Those certain devices are completely obsolete first generation Intel
SSDs.

> Update nvme_update_disk_info() to allow the presence of the DEALLOCATE_ZEROES
> quirk (combined with DSM support) to set max_hw_wzeroes_unmap_sectors to enable

No. This was a hack that got sneaked in in the first days of the nvme
driver and never should have been there.  It most certainly should not
be extended to any new functionality.

Hi Christoph

On Fri, Mar 6, 2026 at 6:24 AM Christoph Hellwig <hch@lst.de> wrote:
>
> On Thu, Mar 05, 2026 at 12:27:32PM -0800, Robert Pang wrote:
> > However, certain devices already use the NVME_QUIRK_DEALLOCATE_ZEROES quirk to
> > indicate that they deterministically return zeroes after a deallocate/discard
>
> Those certain devices are completely obsolete first generation Intel
> SSDs.
>
> > Update nvme_update_disk_info() to allow the presence of the DEALLOCATE_ZEROES
> > quirk (combined with DSM support) to set max_hw_wzeroes_unmap_sectors to enable
>
> No. This was a hack that got sneaked in in the first days of the nvme
> driver and never should have been there.  It most certainly should not
> be extended to any new functionality.
>

Thank you for your review and for providing the historical context
regarding this quirk. Given these insights, we can discard this patch
proposal.

Best regards
Robert Pang

Hi Robert,

On 3/11/2026 1:14 AM, Robert Pang wrote:
> Hi Christoph
> 
> On Fri, Mar 6, 2026 at 6:24 AM Christoph Hellwig <hch@lst.de> wrote:
>>
>> On Thu, Mar 05, 2026 at 12:27:32PM -0800, Robert Pang wrote:
>>> However, certain devices already use the NVME_QUIRK_DEALLOCATE_ZEROES quirk to
>>> indicate that they deterministically return zeroes after a deallocate/discard
>>
>> Those certain devices are completely obsolete first generation Intel
>> SSDs.
>>
>>> Update nvme_update_disk_info() to allow the presence of the DEALLOCATE_ZEROES
>>> quirk (combined with DSM support) to set max_hw_wzeroes_unmap_sectors to enable
>>
>> No. This was a hack that got sneaked in in the first days of the nvme
>> driver and never should have been there.  It most certainly should not
>> be extended to any new functionality.
>>
> 
> Thank you for your review and for providing the historical context
> regarding this quirk. Given these insights, we can discard this patch
> proposal.
> 

I just wonder if you have such hardware and use cases, or if you simply
want to supplement this feature for those corner devices?

Best regards
Yi.

> Best regards
> Robert Pang

Hi Zhang Yi

On Tue, Mar 10, 2026 at 7:56 PM Zhang Yi <yi.zhang@huaweicloud.com> wrote:
>
> Hi Robert,
>
> On 3/11/2026 1:14 AM, Robert Pang wrote:
> > Hi Christoph
> >
> > On Fri, Mar 6, 2026 at 6:24 AM Christoph Hellwig <hch@lst.de> wrote:
> >>
> >> On Thu, Mar 05, 2026 at 12:27:32PM -0800, Robert Pang wrote:
> >>> However, certain devices already use the NVME_QUIRK_DEALLOCATE_ZEROES quirk to
> >>> indicate that they deterministically return zeroes after a deallocate/discard
> >>
> >> Those certain devices are completely obsolete first generation Intel
> >> SSDs.
> >>
> >>> Update nvme_update_disk_info() to allow the presence of the DEALLOCATE_ZEROES
> >>> quirk (combined with DSM support) to set max_hw_wzeroes_unmap_sectors to enable
> >>
> >> No. This was a hack that got sneaked in in the first days of the nvme
> >> driver and never should have been there.  It most certainly should not
> >> be extended to any new functionality.
> >>
> >
> > Thank you for your review and for providing the historical context
> > regarding this quirk. Given these insights, we can discard this patch
> > proposal.
> >
>
> I just wonder if you have such hardware and use cases, or if you simply
> want to supplement this feature for those corner devices?
>

It is the latter.

Best regards
Robert Pang

> Best regards
> Yi.