From patchwork Tue Aug 22 17:33:01 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Omar Sandoval X-Patchwork-Id: 9915831 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 EF51960381 for ; Tue, 22 Aug 2017 17:33:21 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id D8882283ED for ; Tue, 22 Aug 2017 17:33:21 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id CD574287EC; Tue, 22 Aug 2017 17:33:21 +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,DKIM_SIGNED, DKIM_VALID, RCVD_IN_DNSWL_HI, RCVD_IN_SORBS_SPAM 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 7F6EB283ED for ; Tue, 22 Aug 2017 17:33:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752388AbdHVRdU (ORCPT ); Tue, 22 Aug 2017 13:33:20 -0400 Received: from mail-pg0-f44.google.com ([74.125.83.44]:35736 "EHLO mail-pg0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751877AbdHVRdS (ORCPT ); Tue, 22 Aug 2017 13:33:18 -0400 Received: by mail-pg0-f44.google.com with SMTP id u191so43290431pgc.2 for ; Tue, 22 Aug 2017 10:33:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=osandov-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references :in-reply-to:references; bh=deJyGXjWgt19Vmm0ufPmP9VONTuiqnykmr/iSp17HAM=; b=u9RnyfbJ6OyOWO0uXu7mmJrPHj4nQL44xYD0zaFLcvU0vZm5jJ42FJi6RceKmKFkTA mMoPmO6Ryo59f6ARf5kp86xNxX828dUx+dcS1Yv8VRBnboiY28CIdYsujzeoNHOGc5mE hTZGR1gyAkObK+r0YsWMzowIWIdCAVI6NplCbGwDA0abohJY/Lf18d3Kqyk5aQmqmh1b 9xnq7hb9fznL2V0xufhGWJMd+K3SMHB28aK6F8lV2mvZMYRn+v2cOaUnf8+peES3+tdx nz13J9PKDQ/vtSkndf66ex2PY6g5n+NsjNCZVvIOmi5xgCFaC0RYOblLWz3Mw2YIZmJJ Djkw== 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:in-reply-to :references:in-reply-to:references; bh=deJyGXjWgt19Vmm0ufPmP9VONTuiqnykmr/iSp17HAM=; b=RfqwLy5pM2aJY6eZuXHy0Fc3yJi6C3oazxfy1CBhmlU77hZDUj8G3wDb+1+H/ZP7kk p337yQLCvGsULDAmNAF/c6V+krK6MIvckc4jnd22a+FqkFzJuFUEnE11dQTAqGx2g8SN C08hMw2N7YGAOCQftlO1HDaPBS0Aet37VttXJkt4RAZYI8B34UQYm0Gg5mDLyUTYzJI4 PFbUKFlm3ueBqr1um9FMWHYuS/EbCF0tyDF2/1yD01OCer2Y1e/sAMExejcRT4k1OA+L /xnZal4RNfCj9d2tcQMlT1zYdvuBeu5ufyGni4DzsrXHdev1pOV+9famypXGu69NY+CS qxWA== X-Gm-Message-State: AHYfb5hEvtGIaqsYv8n3xzkQy+AcXWm7gGWdP0PSb0OVt1ljvr4RrzNH i25tU60nc0g53DCe+MLTwA== X-Received: by 10.84.128.34 with SMTP id 31mr1611824pla.340.1503423197758; Tue, 22 Aug 2017 10:33:17 -0700 (PDT) Received: from vader.thefacebook.com ([2620:10d:c090:200::6:99f5]) by smtp.gmail.com with ESMTPSA id m10sm4920083pgd.62.2017.08.22.10.33.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 Aug 2017 10:33:16 -0700 (PDT) From: Omar Sandoval To: linux-block@vger.kernel.org Cc: kernel-team@fb.com, Hannes Reinecke , Ming Lei , Karel Zak , Milan Broz Subject: [PATCH v3 4/4] loop: always return block size in LOOP_GET_STATUS Date: Tue, 22 Aug 2017 10:33:01 -0700 Message-Id: <778264213d9a05c70fc99e067eab2105230aa95e.1503422996.git.osandov@fb.com> X-Mailer: git-send-email 2.14.1 In-Reply-To: References: In-Reply-To: References: 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 From: Omar Sandoval When I was writing a test for the new loop device block size functionality, I noticed a couple of issues with how LOOP_GET_STATUS handles the block size: - lo_init[0] is never filled in with the logical block size we previously set - lo_flags returned from LOOP_GET_STATUS will have LO_FLAGS_BLOCKSIZE set if we previously called LOOP_SET_STATUS with LO_FLAGS_BLOCKSIZE set, which doesn't really mean anything Instead, for LOOP_GET_STATUS, let's always fill in lo_init[0] and set the LO_FLAGS_BLOCKSIZE flag to indicate we support it. Tested-by: Milan Broz Reviewed-by: Hannes Reinecke Signed-off-by: Omar Sandoval --- drivers/block/loop.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/block/loop.c b/drivers/block/loop.c index 28026f0abaa9..b55a1f82f561 100644 --- a/drivers/block/loop.c +++ b/drivers/block/loop.c @@ -1222,7 +1222,7 @@ loop_get_status(struct loop_device *lo, struct loop_info64 *info) info->lo_rdevice = huge_encode_dev(lo->lo_device ? stat.rdev : stat.dev); info->lo_offset = lo->lo_offset; info->lo_sizelimit = lo->lo_sizelimit; - info->lo_flags = lo->lo_flags; + info->lo_flags = lo->lo_flags | LO_FLAGS_BLOCKSIZE; memcpy(info->lo_file_name, lo->lo_file_name, LO_NAME_SIZE); memcpy(info->lo_crypt_name, lo->lo_crypt_name, LO_NAME_SIZE); info->lo_encrypt_type = @@ -1232,6 +1232,7 @@ loop_get_status(struct loop_device *lo, struct loop_info64 *info) memcpy(info->lo_encrypt_key, lo->lo_encrypt_key, lo->lo_encrypt_key_size); } + LO_INFO_BLOCKSIZE(info) = queue_logical_block_size(lo->lo_queue); return 0; }