From patchwork Thu Aug 11 08:26:39 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tom Yan X-Patchwork-Id: 9274621 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 6453D6022E for ; Thu, 11 Aug 2016 08:27:02 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 51AA128561 for ; Thu, 11 Aug 2016 08:27:02 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 4618628563; Thu, 11 Aug 2016 08:27:02 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,FREEMAIL_FROM,RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id E702328561 for ; Thu, 11 Aug 2016 08:27:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752388AbcHKI07 (ORCPT ); Thu, 11 Aug 2016 04:26:59 -0400 Received: from mail-pf0-f193.google.com ([209.85.192.193]:35815 "EHLO mail-pf0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750909AbcHKI04 (ORCPT ); Thu, 11 Aug 2016 04:26:56 -0400 Received: by mail-pf0-f193.google.com with SMTP id h186so4426930pfg.2; Thu, 11 Aug 2016 01:26:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id; bh=xkNpUX8i8nhYMVAoLOU+/pcD8/FODvHZMsPeIyinqTQ=; b=kW+KxFc2ApGrzB9PcSL3aiqiqdNRHtvD0h1c6NxHfjuMIMBmiSmNLaKqX+v3WdIz7z fUuFUNRPtrNyfOv2lLRw99pzOXo3KSk2XGzgLjtczcVwThtFZz6DFTTlZceA8NS2pJrR /1RS53vzHnkYG+7sfrjMcq36A5O+9JbF/kfgkyVU5Te6DK+nZMMg3xpuh/DosPk5yGYy zjF1weKDv0DNqJmvlfbFoqmN7UN21xnnkTVVpXIdB0nasb9Ng/WUOEBifE3p87TIu/kv gtN2tITwntS6gVmQr72Go2U720ArCR0ItxoN0WvnXWIY+WkJOp5YfOmzuzjBD+OvdbzM JUUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=xkNpUX8i8nhYMVAoLOU+/pcD8/FODvHZMsPeIyinqTQ=; b=G/GRpxnMEptI5U0UIh6bzGhp/lpUhjbUFrZksGGIBMzZ1nm4VGrwse2kzDwrMOvnpY z5V0SGEKfsxUtXGO9pWefBMpLFe5uairW/NRhfhU5Pdj5V8SGSIzkkgomln6sIMfoBvj pi4h/1Cdzy5nd2J0CFd2bd7Odopg6svPl3MMl9tQX7w37wP6uBR+LbSl0mw3L8Db675c Gkh+dgdEaagGtibNkFalgS0N160Tx8xtgZ6UmvdrbbzzxVCAWNryAY3c/h9Q0HCe0u7q mSQ+O/miODr7ohRMEyGyKqAYHm6dPm8M7Bsilor7eGPk21rVSzyuqRf+vXmP0vKsZ0Cr eNcg== X-Gm-Message-State: AEkoouuNS4en8vfRjViVWfa8dTV19bRtqzKRnbcrT1h4/Y6ZdOwsvicHgv2CKx5uQLoEyA== X-Received: by 10.98.72.28 with SMTP id v28mr14788639pfa.139.1470904007649; Thu, 11 Aug 2016 01:26:47 -0700 (PDT) Received: from localhost.localdomain ([2404:c805:e00:4700:ae22:bff:fe29:e60c]) by smtp.gmail.com with ESMTPSA id u72sm3017931pfa.31.2016.08.11.01.26.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Aug 2016 01:26:47 -0700 (PDT) From: tom.ty89@gmail.com X-Google-Original-From: me To: tj@kernel.org, shaun.tancheff@seagate.com, shaun@tancheff.com, martin.petersen@oracle.com Cc: linux-ide@vger.kernel.org, linux-scsi@vger.kernel.org, linux-block@vger.kernel.org, Tom Yan Subject: [RFC] libata-scsi: make sure Maximum Write Same Length is not too large Date: Thu, 11 Aug 2016 16:26:39 +0800 Message-Id: <833713246c1a70d85150289c1537797d6f7dd606.1470903899.git.tom.ty89@gmail.com> X-Mailer: git-send-email 2.9.2 Sender: linux-scsi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-scsi@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Tom Yan Currently we advertise Maximum Write Same Length based on the maximum number of sectors that one-block TRIM payload can cover. The field are used to derived discard_max_bytes and write_same_max_bytes limits in the block layer, which currently can at max be 0xffffffff (32-bit). However, with a AF 4Kn drive, the derived limits would be 65535 * 64 * 4096 = 0x3fffc0000 (34-bit). Therefore, we now devide ATA_MAX_TRIM_RNUM with (logical sector size / 512), so that the derived limits will not overflow. The limits are now also consistent among drives with different logical sector sizes. (Although that may or may not be what we want ultimately when the SCSI / block layer allows larger representation in the future.) Although 4Kn ATA SSDs may not be a thing on the market yet, this patch is necessary for forthcoming SCT Write Same translation support, which could be available on traditional HDDs where 4Kn is already a thing. Also it should not change the current behavior on drives with 512-byte logical sectors. Note: this patch is not about AF 512e drives. Signed-off-by: Tom Yan diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c index be9c76c..dcadcaf 100644 --- a/drivers/ata/libata-scsi.c +++ b/drivers/ata/libata-scsi.c @@ -2295,6 +2295,7 @@ static unsigned int ata_scsiop_inq_89(struct ata_scsi_args *args, u8 *rbuf) static unsigned int ata_scsiop_inq_b0(struct ata_scsi_args *args, u8 *rbuf) { u16 min_io_sectors; + u32 sector_size; rbuf[1] = 0xb0; rbuf[3] = 0x3c; /* required VPD size with unmap support */ @@ -2309,17 +2310,27 @@ static unsigned int ata_scsiop_inq_b0(struct ata_scsi_args *args, u8 *rbuf) min_io_sectors = 1 << ata_id_log2_per_physical_sector(args->id); put_unaligned_be16(min_io_sectors, &rbuf[6]); - /* - * Optimal unmap granularity. - * - * The ATA spec doesn't even know about a granularity or alignment - * for the TRIM command. We can leave away most of the unmap related - * VPD page entries, but we have specifify a granularity to signal - * that we support some form of unmap - in thise case via WRITE SAME - * with the unmap bit set. - */ + sector_size = ata_id_logical_sector_size(args->id); if (ata_id_has_trim(args->id)) { - put_unaligned_be64(65535 * ATA_MAX_TRIM_RNUM, &rbuf[36]); + /* + * Maximum write same length. + * + * Avoid overflow in discard_max_bytes and write_same_max_bytes + * with AF 4Kn drives. Also make them consistent among drives + * with different logical sector sizes. + */ + put_unaligned_be64(65535 * ATA_MAX_TRIM_RNUM / + (sector_size / 512), &rbuf[36]); + + /* + * Optimal unmap granularity. + * + * The ATA spec doesn't even know about a granularity or alignment + * for the TRIM command. We can leave away most of the unmap related + * VPD page entries, but we have specifify a granularity to signal + * that we support some form of unmap - in thise case via WRITE SAME + * with the unmap bit set. + */ put_unaligned_be32(1, &rbuf[28]); }