From patchwork Thu Dec 6 22:20:29 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jens Axboe X-Patchwork-Id: 10717121 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id E15A31759 for ; Thu, 6 Dec 2018 22:20:34 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id D04E92EFB3 for ; Thu, 6 Dec 2018 22:20:34 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id C51232EFD3; Thu, 6 Dec 2018 22:20:34 +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=-7.9 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=ham 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 A44532EFCD for ; Thu, 6 Dec 2018 22:20:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726018AbeLFWUc (ORCPT ); Thu, 6 Dec 2018 17:20:32 -0500 Received: from mail-io1-f68.google.com ([209.85.166.68]:44535 "EHLO mail-io1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725939AbeLFWUc (ORCPT ); Thu, 6 Dec 2018 17:20:32 -0500 Received: by mail-io1-f68.google.com with SMTP id r200so1683076iod.11 for ; Thu, 06 Dec 2018 14:20:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20150623.gappssmtp.com; s=20150623; h=to:cc:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=T+SEFfR31RhWVxomNCLe19Q87AMxJcdwzmDYNMbLTrE=; b=FIbxAGZUr+deRGDfUHnrQcg1x/g+S0+iFQh4BYLKx6t9Y8p1SHieWK2Re/Jl5TERxX KSCcfAecdux1nr77ESYGHAIIxZN7iOYsw0FjWWwjqBGJVE9KtqtiHZCsGgIT6uf6FXz7 fK8QdkZsXo5zq2pXTp8/P2fqkmBlalMuWcTw4JDf0sO/tR6AW9C8bL/67Ve2lu5wuXl6 Untg/gAHJ+TcsLXf8lSnDy1/FgDWT7oZz/H4fQniDLNCBu2uKuKVP7f8UTTUBR1tUk7H 99+vnwzy2n99kdo9X8aIQEIv/8F9L+E68yKNKX1RFk7ZV5wY8Rjize7lEYBkcTh3wKxP x6hA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=T+SEFfR31RhWVxomNCLe19Q87AMxJcdwzmDYNMbLTrE=; b=rm1YkzsX9tOleVzZlUx5qFKg9Zl9EO0QBlcZQ7F+GsVB0L1l4XAthn3UMKvXucFUGQ X36RZlbVkyNHS1vZaAESAGYsTVQOIrFVh9/hwKacFMFX1E3jY01TdAyzC8gVq7+0tR7C 320LM2liWjyui9qXEsuy+P2ay1c5erFUDLiV/y6LSJBTBqwxnp0ip/dPkZjvoGZHV0Sg 3+FV6j0RfOXqOG0zxzo2VbGLwIJfS1JgF2gOUv2rMubLjTLKv2It16x3FAwA31u04Biv 5iK1y+DsYDrrxkp47pX/sDqoDIu5a7Zi2FA/WBGc7gd+sO1RAhpZkY85JisBYVZBakBR 0MjA== X-Gm-Message-State: AA+aEWb7K7pHbOd2qiUZ+Mvcw2w2JDFPcSy0pzd0zVB2x4p08IAEvTTJ o6hyqHB+eEPO9nWLpWfO0PxZpg== X-Google-Smtp-Source: AFSGD/U7xNzJ9tDfcQ22uCcRO0UwVhC5vTx7M2ERUgKy9bqOQdOTs14vX4qILfBhEsMZ5kHL1yBcAg== X-Received: by 2002:a6b:4106:: with SMTP id n6mr25640174ioa.171.1544134831806; Thu, 06 Dec 2018 14:20:31 -0800 (PST) Received: from [192.168.1.56] ([216.160.245.98]) by smtp.gmail.com with ESMTPSA id t10sm669395ioi.4.2018.12.06.14.20.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Dec 2018 14:20:30 -0800 (PST) To: "linux-block@vger.kernel.org" Cc: Bart Van Assche , Mike Snitzer From: Jens Axboe Subject: [PATCH] block: fix direct dispatch issue failure for clones Message-ID: Date: Thu, 6 Dec 2018 15:20:29 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 Content-Language: en-US Sender: linux-block-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP After the direct dispatch corruption fix, we permanently disallow direct dispatch of non read/write requests. This works fine off the normal IO path, as they will be retried like any other failed direct dispatch request. But for the blk_insert_cloned_request() that only DM uses to bypass the bottom level scheduler, we always first attempt direct dispatch. For some types of requests, that's now a permanent failure, and no amount of retrying will make that succeed. Don't use direct dispatch off the cloned insert path, always just use bypass inserts. This still bypasses the bottom level scheduler, which is what DM wants. Fixes: ffe81d45322c ("blk-mq: fix corruption with direct issue") Signed-off-by: Jens Axboe Acked-by: Mike Snitzer Tested-by: Bart Van Assche diff --git a/block/blk-core.c b/block/blk-core.c index deb56932f8c4..4c44e6fa0d08 100644 --- a/block/blk-core.c +++ b/block/blk-core.c @@ -2637,7 +2637,8 @@ blk_status_t blk_insert_cloned_request(struct request_queue *q, struct request * * bypass a potential scheduler on the bottom device for * insert. */ - return blk_mq_request_issue_directly(rq); + blk_mq_request_bypass_insert(rq, true); + return BLK_STS_OK; } spin_lock_irqsave(q->queue_lock, flags);