From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_PASS,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5642BC282C4 for ; Thu, 7 Feb 2019 20:57:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2135C2175B for ; Thu, 7 Feb 2019 20:57:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="I/qIQQnj" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727557AbfBGU5r (ORCPT ); Thu, 7 Feb 2019 15:57:47 -0500 Received: from mail-pl1-f194.google.com ([209.85.214.194]:44660 "EHLO mail-pl1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726691AbfBGU5q (ORCPT ); Thu, 7 Feb 2019 15:57:46 -0500 Received: by mail-pl1-f194.google.com with SMTP id p4so518008plq.11 for ; Thu, 07 Feb 2019 12:57:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=xawq7z+PV/ZeUtaPhAzsAhOVrlvuexv6AC5ScinQK0A=; b=I/qIQQnjRV9FFCrMc7YME6bXm0jctteW4Ua54tUdFY1I/kwK9q6Z13N77e32dDxQl4 WoH4nzd9kv7WYPomUK04WbKYBmF21X9i1LtpjVRhYoVdMS8kPySxv+QZ2We1MsdMAeeK kfYyoLb/PvSO3Z4NPGNYHv82L1hAdG6GCRbWs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=xawq7z+PV/ZeUtaPhAzsAhOVrlvuexv6AC5ScinQK0A=; b=uV/wEbhkUWnhZRCTRqR/9uuPNXaIIaYia0bJoRxzKaMpf3YNVv7H94vlE7bqazubKE 5QsOUjDoqoMLZ9ElZTXdfbkE4CvAcHIBbaEzI0sMhIDLbHkyFnqjfrzqLkTcH3J/Cj2p np3mnIyAs6jjz7Kf1ah3/d2Q5ZApsKRlIEKZ/ndYjr2Dw5dO1AAlHHgDMF8mk8FCYxl7 2atGDyXva9qK+moRG6Z2GP9FJyuA6mIga71uU9dE56ogNvBcpI2B8GrcBAG/EF5v/V/A UNEc12rN3zef1t5SH/y48S01j5WB83Q9YurqYrGPfXsnMCcnGpFPBNdN+1N2yAoxT1Lr rEGA== X-Gm-Message-State: AHQUAubcIVjzx1+LGminSUtoy1L2Ti/XiniRRr/HSrm26JD/eAHOrIi3 DlgVLp11+LveZk1YxQewGevzTA== X-Google-Smtp-Source: AHgI3IYrkOimqveRulGTCpIkCCpDlDv9UFrr3WKuXnb8tZfu1DRmCUxwjG2qzBFsIs4Nhao3tPADbQ== X-Received: by 2002:a17:902:bd86:: with SMTP id q6mr18189270pls.16.1549573065734; Thu, 07 Feb 2019 12:57:45 -0800 (PST) Received: from evgreen2.mtv.corp.google.com ([2620:15c:202:201:ffda:7716:9afc:1301]) by smtp.gmail.com with ESMTPSA id y9sm27199pfi.74.2019.02.07.12.57.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 07 Feb 2019 12:57:44 -0800 (PST) From: Evan Green To: Jens Axboe Cc: Bart Van Assche , Gwendal Grignou , Martin K Petersen , Alexis Savery , Ming Lei , Evan Green , linux-block@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 0/2] loop: Better discard for block devices Date: Thu, 7 Feb 2019 12:57:27 -0800 Message-Id: <20190207205730.199332-1-evgreen@chromium.org> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This series addresses some errors seen when using the loop device directly backed by a block device. The first change plumbs out the correct error message, and the second change prevents the error from occurring in many cases. The errors look like this: [ 90.880875] print_req_error: I/O error, dev loop5, sector 0 The errors occur when trying to do a discard or write zeroes operation on a loop device backed by a block device that does not support discard. Firstly, the error itself is incorrectly reported as I/O error, but is actually EOPNOTSUPP. The first patch plumbs out EOPNOTSUPP to properly report the error. The second patch prevents these errors from occurring by mirroring the discard capabilities of the underlying block device into the loop device. Before this change, discard was always reported as being supported, and the loop device simply turns around and does a discard operation on the backing device. After this change, backing block devices that do support discard will continue to work as before, and continue to get all the benefits of doing that. Backing devices that do not support discard will fail earlier, avoiding hitting the loop device at all and ultimately avoiding this error in the logs. I can also confirm that this fixes test block/003 in the blktests, when running blktests on a loop device backed by a block device. Changes in v2: - Unnested error if statement (Bart) Evan Green (2): loop: Report EOPNOTSUPP properly loop: Better discard support for block devices drivers/block/loop.c | 70 ++++++++++++++++++++++++++++++-------------- 1 file changed, 48 insertions(+), 22 deletions(-) -- 2.20.1