From patchwork Fri Jun 23 15:18:16 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jens Axboe X-Patchwork-Id: 9806773 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 CC42060329 for ; Fri, 23 Jun 2017 15:18:27 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id BB658286A7 for ; Fri, 23 Jun 2017 15:18:27 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id B001C28799; Fri, 23 Jun 2017 15:18:27 +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.4 required=2.0 tests=BAYES_00,BIGNUM_EMAILS, DKIM_SIGNED,DKIM_VALID,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 A04B1286A7 for ; Fri, 23 Jun 2017 15:18:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754411AbdFWPSU (ORCPT ); Fri, 23 Jun 2017 11:18:20 -0400 Received: from mail-it0-f54.google.com ([209.85.214.54]:37940 "EHLO mail-it0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754423AbdFWPST (ORCPT ); Fri, 23 Jun 2017 11:18:19 -0400 Received: by mail-it0-f54.google.com with SMTP id b205so9914206itg.1 for ; Fri, 23 Jun 2017 08:18:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=tSpvpPydgnoq1+/qBXjxLgmSvF0kju8MoqOhYs5tBp8=; b=0HwXqMPxzrDa6OOhGTGumry0W3zI8lQBYsQCuzfwoCKSz3lbq6bzLqKCZ5qCwrklVw fDpN2vH+MQVx6GapgYlhR3ct0FK9C39GkoSGRA/poxR7MuIVL5yhtjdl2YqYQ6go3xoH i30s3EKZs8VQ1EgEXAxFYzURolkr3QsN5lSU0d9LCUWRBhB8aUfq9gMcikSi6Vp4RoRb iK6RFSl/K1GwAtuHEpZUC+nYHQBIrIiJ/Bffxw5sF/nNB/317iURswJYO8aSK5OUlHHd U04ELdlWzJwDvzjaI5zdK21t+G3lIFceSRCRfLEW9bJdUBzFzFtGhXIMFoB2OwbdIJ2D ip7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=tSpvpPydgnoq1+/qBXjxLgmSvF0kju8MoqOhYs5tBp8=; b=XBvk4S0o79az94xtNQZqqE+Be+A6dz2NkeQt5xUvTf2LaGnhQOPaD5MohqzheKwYUa gdWU4e1xXbXaHPM6LXc7gE+8iMKNwfgduU1C4UG3drkDdlIyS4z1o68X5QW3a4MIkBm5 FnyG3n4dxMwQzq85o5GbvIVlpR1mcR/iPpL0MlyJUu4xDYc1wMN7d64nHNyKWFl3R14t A0ZLl/1QqiP5VmbBr45or8nE8A9AKdifrOsbsVUVD35RbWuBzHxvhxM2BYOHTkjGJcdG 2BtJE1ZX6ChLHI739almIZEAhym0YRKvgmgx2cAtL7TwfPTYJc7IFJPlOYidaeh/XOeu DRzw== X-Gm-Message-State: AKS2vOw/3Z8NC5fK/e82F+Q3pN5H1JNFCnPsgfWL4lLqTLhsS+bdofMG buaLHoEmM/e/OBATnIq2NQ== X-Received: by 10.36.80.14 with SMTP id m14mr7969586itb.31.1498231098212; Fri, 23 Jun 2017 08:18:18 -0700 (PDT) Received: from [192.168.1.154] ([216.160.245.98]) by smtp.gmail.com with ESMTPSA id 137sm3109621itw.14.2017.06.23.08.18.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Jun 2017 08:18:17 -0700 (PDT) Subject: Re: [bug report] mtip32xx: convert internal command issue to block IO path To: Dan Carpenter Cc: linux-block@vger.kernel.org References: <20170623090506.GA7127@elgon.mountain> From: Jens Axboe Message-ID: Date: Fri, 23 Jun 2017 09:18:16 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <20170623090506.GA7127@elgon.mountain> 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 On 06/23/2017 03:05 AM, Dan Carpenter wrote: > Hello Jens Axboe, > > The patch 3f5e6a35774c: "mtip32xx: convert internal command issue to > block IO path" from Apr 28, 2017, leads to the following static > checker warning: > > drivers/block/mtip32xx/mtip32xx.c:1067 mtip_exec_internal_command() > warn: 'int_cmd->status' is unsigned > > drivers/block/mtip32xx/mtip32xx.c > 1065 > 1066 rv = int_cmd->status; > ^^^^^^^^^^^^^^^ > This is a new block error code. > > 1067 if (rv < 0) { > ^^^^^^ > So this doesn't make sense. This used to be rv <= 0. It's actually two layers of breakage. After the referenced commit, some of the below were wonky. But the new breakage is: commit 2a842acab109f40f0d7d10b38e9ca88390628996 Author: Christoph Hellwig Date: Sat Jun 3 09:38:04 2017 +0200 block: introduce new block status code type since that means that int_cmd->status is a blk_status_t, it's not an -Exx value at all. And that patch changed the cmd->status field from an int to a u8, which is why you are now seeing complaints. The below should do the trick. All we really care about is whether ->staut is zero or not. Just turn that into EIO, and dump the various attempts at clever reporting. diff --git a/drivers/block/mtip32xx/mtip32xx.c b/drivers/block/mtip32xx/mtip32xx.c index d8618a71da74..61b046f256ca 100644 --- a/drivers/block/mtip32xx/mtip32xx.c +++ b/drivers/block/mtip32xx/mtip32xx.c @@ -1063,23 +1063,10 @@ static int mtip_exec_internal_command(struct mtip_port *port, /* insert request and run queue */ blk_execute_rq(rq->q, NULL, rq, true); - rv = int_cmd->status; - if (rv < 0) { - if (rv == -ERESTARTSYS) { /* interrupted */ - dev_err(&dd->pdev->dev, - "Internal command [%02X] was interrupted after %u ms\n", - fis->command, - jiffies_to_msecs(jiffies - start)); - rv = -EINTR; - goto exec_ic_exit; - } else if (rv == 0) /* timeout */ - dev_err(&dd->pdev->dev, - "Internal command did not complete [%02X] within timeout of %lu ms\n", - fis->command, timeout); - else - dev_err(&dd->pdev->dev, - "Internal command [%02X] wait returned code [%d] after %lu ms - unhandled\n", - fis->command, rv, timeout); + if (int_cmd->status) { + dev_err(&dd->pdev->dev, "Internal command [%02X] failed %d\n", + fis->command, int_cmd->status); + rv = -EIO; if (mtip_check_surprise_removal(dd->pdev) || test_bit(MTIP_DDF_REMOVE_PENDING_BIT,