From patchwork Fri Jun 3 13:42:17 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tim Gardner X-Patchwork-Id: 629837 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from huckleberry.canonical.com (huckleberry.canonical.com [91.189.94.19]) by ozlabs.org (Postfix) with ESMTP id 3rLldm6yvGz9t60; Fri, 3 Jun 2016 23:42:36 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=canonical-com.20150623.gappssmtp.com header.i=@canonical-com.20150623.gappssmtp.com header.b=ZUSCqxIz; dkim-atps=neutral Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.76) (envelope-from ) id 1b8pMv-0001PO-D3; Fri, 03 Jun 2016 13:42:33 +0000 Received: from mail-it0-f43.google.com ([209.85.214.43]) by huckleberry.canonical.com with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1b8pMo-0001O7-R7 for kernel-team@lists.ubuntu.com; Fri, 03 Jun 2016 13:42:26 +0000 Received: by mail-it0-f43.google.com with SMTP id i127so80141654ita.1 for ; Fri, 03 Jun 2016 06:42:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical-com.20150623.gappssmtp.com; s=20150623; h=from:to:subject:date:message-id:in-reply-to:references; bh=zM3OxxC4t//xDwKJ3tCHHIhtjn0GxS7dLuXG5zIjD3s=; b=ZUSCqxIz5OTtjnVNipb6yc8XlWXCqc/S5YfAF+F32lR6WIkoyQPRr1CT07Akcvl6Tu riYYopQhll0wnIhcJESooqHyvOLoEi1PoMTORAqt+CqT8xOQ6DuhLFynGhfBYroGHXGp 0L/bYBw32gkD/wZ5WdvyRDT5hi8DSaWoOR2bMnZja/LdBifD2HXKTtPUA5O8Ggrz++o1 FHYOAaq5xMdGAUBeHYfa5zY6Q8EUCV2C29PpLV+IuVQIbcPSx114XrT5xT2fqJa1pQvL Tahxmd5MH1MC3Kvmekx9PRCFPTdM29fZXgz57wpKFsweghr5hedKS2tkIwJGt78zMU5w zdKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references; bh=zM3OxxC4t//xDwKJ3tCHHIhtjn0GxS7dLuXG5zIjD3s=; b=YX4DZZVudIEQl0LEWBXU/v38nDL5XuurSsxmgmSOcVGIJuFSKfnExvnWX189s2HWMA 1HwCCM0HJptaL4XIY9D+UYinSZHEvG8rPYVyGI7Zij7X+6Sxx0efPW8Ridx4yhHSrJuH 3jhiMgPs+0JFiLKb4//ZIKv4yLX23y5D65Tx1t3LhGQl1nmG3I3+BB/25Ht5sqVx+wT+ gvKegYdDblBLm00d0jpj9spt2pfMMnS2siNf6lWyoPN9U0rhtCBrtkWxBuyqY/XBjLQW dkV/faI48n8vw6JPzneNLb41YL5CIbUW0w8ZBqzF+r26TY+bawihTnB1OfoDk9YetF6j Vmuw== X-Gm-Message-State: ALyK8tLfg7Rv2vXWjB8Nw7JnGHmtgvXTYstf2dJjt/7l3Ce4slyVu2mt4mPUTfvhulalYVqc X-Received: by 10.36.11.84 with SMTP id 81mr5081398itd.89.1464961345643; Fri, 03 Jun 2016 06:42:25 -0700 (PDT) Received: from localhost.localdomain (host-174-45-44-32.hln-mt.client.bresnan.net. [174.45.44.32]) by smtp.gmail.com with ESMTPSA id q131sm2788652iod.40.2016.06.03.06.42.25 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 03 Jun 2016 06:42:25 -0700 (PDT) From: Tim Gardner To: kernel-team@lists.ubuntu.com Subject: [PATCH 3/3 Xenial SRU] block: fix blk_rq_get_max_sectors for driver private requests Date: Fri, 3 Jun 2016 07:42:17 -0600 Message-Id: <1464961337-19608-3-git-send-email-tim.gardner@canonical.com> X-Mailer: git-send-email 1.9.1 In-Reply-To: <1464961337-19608-1-git-send-email-tim.gardner@canonical.com> References: <1464961337-19608-1-git-send-email-tim.gardner@canonical.com> X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.14 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: kernel-team-bounces@lists.ubuntu.com From: Christoph Hellwig BugLink: http://bugs.launchpad.net/bugs/1588449 Driver private request types should not get the artifical cap for the FS requests. This is important to use the full device capabilities for internal command or NVMe pass through commands. Signed-off-by: Christoph Hellwig Reported-by: Jeff Lien Tested-by: Jeff Lien Reviewed-by: Keith Busch Updated by me to use an explicit check for the one command type that does support extended checking, instead of relying on the ordering of the enum command values - as suggested by Keith. Signed-off-by: Jens Axboe (cherry picked from commit f21018427cb007a0894c36ad702990ab639cbbb4) Signed-off-by: Tim Gardner --- include/linux/blkdev.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h index 9ecdb59..42f4bcf 100644 --- a/include/linux/blkdev.h +++ b/include/linux/blkdev.h @@ -890,7 +890,7 @@ static inline unsigned int blk_rq_get_max_sectors(struct request *rq) { struct request_queue *q = rq->q; - if (unlikely(rq->cmd_type == REQ_TYPE_BLOCK_PC)) + if (unlikely(rq->cmd_type != REQ_TYPE_FS)) return q->limits.max_hw_sectors; if (!q->limits.chunk_sectors || (rq->cmd_flags & REQ_DISCARD))