Received: by 2002:a05:6358:45e:b0:b5:b6eb:e1f9 with SMTP id 30csp823917rwe; Thu, 25 Aug 2022 09:42:15 -0700 (PDT) X-Google-Smtp-Source: AA6agR7FXRTMw5N+MOQrO/KxMfdcCZo4NsNlvC28e0FvGFh2h77d86A5JgELN29vT0J+JvMNkpNA X-Received: by 2002:a17:907:1c01:b0:6f4:2692:e23 with SMTP id nc1-20020a1709071c0100b006f426920e23mr2972392ejc.243.1661445734824; Thu, 25 Aug 2022 09:42:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1661445734; cv=none; d=google.com; s=arc-20160816; b=PBzvnwP6002jK5woPhhX5hOH9PW24k3NhqHrRcraKLTiecd/2niU4VSxeEKys2LJYV qasNdEoZ3uIhLc6h3fXg5yfnzgnGvuewMPTZtt2LMFNbIKJ/HUA6HK5EBkbuCkLcWqwv KGCV0GErrvISObrzXY0Z/PdeFYZ7KksUsDBFhjLFAUyyxhblkrjQs1SGe6xYkhqXACo3 mi9+cy3vG8Krjm7dzG8D8BBLK7bAov3E8739uiashPptFE1I5+cuOkUZTgqJKeIDIc+C q8RmT3MfhUMtcJbR+4HX6ISGReBD6pqVuzJe8hMKWYq+2JLwj0J5vTlLuG6glw0DwdXI BBEQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=+TU3PGBvOnsLjmAR7D4vdPvXxERWZxGSFa4192ps6Z8=; b=voTDpAcWEJ+dlzScmz9VYnfPRnbA9crPDXHVgL/aNsirZYV2tqPp77v0b7t/2gMeCA 4ok54rvgaA3Xy1PFvkD9uUO3lp/WTqb01b02ngvqeq6EURJU+Wo4y+BE5RMMl4fdReRQ KXdxw9k/AzwU8mDfL1eIC2KF88AW6ZxZacFDZ+4SOvjTrna+f9DeHcTnv7kqLLHXQsHa 8qiBXksoKXDM/dnwZmqBfS17RViDBfTVp3yWhUuFGDc7RLAjY563BCUrP7m2j+pvqcTE aOVq9WNQThJTVykU3zOGfOmwBrLlEZRWcD/aLyFsKxnkNpsAlNd1wwMTGUgO6zXWf8Mi J0sg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=cGocOxtC; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id p11-20020a056402500b00b0043dcc0d6eb4si4291807eda.607.2022.08.25.09.41.48; Thu, 25 Aug 2022 09:42:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=cGocOxtC; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242973AbiHYQPj (ORCPT + 99 others); Thu, 25 Aug 2022 12:15:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33042 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242959AbiHYQP3 (ORCPT ); Thu, 25 Aug 2022 12:15:29 -0400 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 561E7192AF; Thu, 25 Aug 2022 09:15:27 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sin.source.kernel.org (Postfix) with ESMTPS id A5AD3CE27B1; Thu, 25 Aug 2022 16:15:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 66BC6C433C1; Thu, 25 Aug 2022 16:15:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1661444124; bh=MyefAg5QMtTe9G45OGJvSLHtJDZ6Nxt+B/36e/BGodU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=cGocOxtCF6njlitkxhkDCLXDSTKPiSMqazH+G1pz6yicN6AahRiMXMtEEEItK9Qps uvEEG/uCqhiG/RwFdvrNko811/8cLvyGfmpy1ojf+3AXVPH2hpliJyoO7iOxClLoBk K6O74IL6AwOcRc0FvC+xt/E9jl47eJxh+RcCeLEIN8KpOoup7KuTLNbKlHQxgsQxb8 iF3PzTnEfbM+yyKWhqi8QHd258xLUYf0ewS8f7eOBhaEzcd8fSr2AGMBvk/zP3HBWO JEJNoOAziB0la4PaewpTu4OZy6jMHBUl/q9GzmgZj9BbpKC8upnBJRDlyJHD/MOrLt 5nNKZoV2FGXrQ== From: SeongJae Park To: jgross@suse.com, roger.pau@citrix.com Cc: marmarek@invisiblethingslab.com, mheyne@amazon.de, xen-devel@lists.xenproject.org, axboe@kernel.dk, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, SeongJae Park , stable@vger.kernel.org Subject: [PATCH 2/2] xen-blkfront: Advertise feature-persistent as user requested Date: Thu, 25 Aug 2022 16:15:11 +0000 Message-Id: <20220825161511.94922-3-sj@kernel.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220825161511.94922-1-sj@kernel.org> References: <20220825161511.94922-1-sj@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Commit e94c6101e151 ("xen-blkback: Apply 'feature_persistent' parameter when connect") made blkback to advertise its support of the persistent grants feature only if the user sets the 'feature_persistent' parameter of the driver and the frontend advertised its support of the feature. However, following commit 402c43ea6b34 ("xen-blkfront: Apply 'feature_persistent' parameter when connect") made the blkfront to work in the same way. That is, blkfront also advertises its support of the persistent grants feature only if the user sets the 'feature_persistent' parameter of the driver and the backend advertised its support of the feature. Hence blkback and blkfront will never advertise their support of the feature but wait until the other advertises the support, even though users set the 'feature_persistent' parameters of the drivers. As a result, the persistent grants feature is disabled always regardless of the 'feature_persistent' values[1]. The problem comes from the misuse of the semantic of the advertisement of the feature. The advertisement of the feature should means only availability of the feature not the decision for using the feature. However, current behavior is working in the wrong way. This commit fixes the issue by making the blkfront advertises its support of the feature as user requested via 'feature_persistent' parameter regardless of the otherend's support of the feature. [1] https://lore.kernel.org/xen-devel/bd818aba-4857-bc07-dc8a-e9b2f8c5f7cd@suse.com/ Fixes: 402c43ea6b34 ("xen-blkfront: Apply 'feature_persistent' parameter when connect") Cc: # 5.10.x Reported-by: Marek Marczykowski-Górecki Suggested-by: Juergen Gross Signed-off-by: SeongJae Park --- drivers/block/xen-blkfront.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c index 8e56e69fb4c4..dfae08115450 100644 --- a/drivers/block/xen-blkfront.c +++ b/drivers/block/xen-blkfront.c @@ -213,6 +213,9 @@ struct blkfront_info unsigned int feature_fua:1; unsigned int feature_discard:1; unsigned int feature_secdiscard:1; + /* Connect-time cached feature_persistent parameter */ + unsigned int feature_persistent_parm:1; + /* Persistent grants feature negotiation result */ unsigned int feature_persistent:1; unsigned int bounce:1; unsigned int discard_granularity; @@ -1848,7 +1851,7 @@ static int talk_to_blkback(struct xenbus_device *dev, goto abort_transaction; } err = xenbus_printf(xbt, dev->nodename, "feature-persistent", "%u", - info->feature_persistent); + info->feature_persistent_parm); if (err) dev_warn(&dev->dev, "writing persistent grants feature to xenbus"); @@ -2281,7 +2284,8 @@ static void blkfront_gather_backend_features(struct blkfront_info *info) if (xenbus_read_unsigned(info->xbdev->otherend, "feature-discard", 0)) blkfront_setup_discard(info); - if (feature_persistent) + info->feature_persistent_parm = feature_persistent; + if (info->feature_persistent_parm) info->feature_persistent = !!xenbus_read_unsigned(info->xbdev->otherend, "feature-persistent", 0); -- 2.25.1