From: SeongJae Park <sj@kernel.org>
To: SeongJae Park <sj@kernel.org>
Cc: Maximilian Heyne <mheyne@amazon.de>,
jgross@suse.com, roger.pau@citrix.com,
marmarek@invisiblethingslab.com, xen-devel@lists.xenproject.org,
axboe@kernel.dk, linux-block@vger.kernel.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH 2/2] xen-blkfront: Advertise feature-persistent as user requested
Date: Fri, 26 Aug 2022 21:59:24 +0000 [thread overview]
Message-ID: <20220826215924.50813-1-sj@kernel.org> (raw)
In-Reply-To: <20220826212039.50736-1-sj@kernel.org>
On Fri, 26 Aug 2022 21:20:39 +0000 SeongJae Park <sj@kernel.org> wrote:
> Hi Max,
>
> On Fri, 26 Aug 2022 14:26:58 +0000 Maximilian Heyne <mheyne@amazon.de> wrote:
>
> > On Thu, Aug 25, 2022 at 04:15:11PM +0000, SeongJae Park wrote:
> > >
> > > 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: <stable@vger.kernel.org> # 5.10.x
> > > Reported-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
> > > Suggested-by: Juergen Gross <jgross@suse.com>
> > > Signed-off-by: SeongJae Park <sj@kernel.org>
> > > ---
> > > 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;
> >
> > I think setting this here is too late because "feature-persistent" was already
> > written to xenstore via talk_to_blkback but with default 0. So during the
> > connect blkback will not see that the guest supports the feature and falls back
> > to no persistent grants.
> >
> > Tested only this patch with some hacky dom0 kernel that doesn't have the patch
> > from your series yet. Will do more testing next week.
>
> Appreciate for your test! And you're right, this patch is not fixing the issue
> completely. That is, commit 402c43ea6b34 ("xen-blkfront: Apply
> 'feature_persistent' parameter when connect") introduced two bugs. One is the
> misuse of the semantic of the advertisement. It's fixed by this patch. The
> second bug, which you found here, is caching the parameter in a wrong place.
To be fair, I think we should say the misuse of the semantic issue came from
the initial commit[1] that uses only one field for the two different
information (availability of the feature and decision to use the feature), and
the mis-placed caching has introduced by the behavior change commit[2].
[1] 74a852479c68 ("xen-blkfront: add a parameter for disabling of persistent grants")
[2] 402c43ea6b34 ("xen-blkfront: Apply 'feature_persistent' parameter when connect")
Thanks,
SJ
>
> In detail, blkfront does the advertisement before connect (for init and resume)
> and then negotiation after connected. And the blkback does the negotiation
> first, and then the advertisement during the establishing the connection.
> Hence, blkback should cache the parameter just before the negotiation logic
> while blkfront should do that just before the advertisement logic.
>
> The blkback behavior change commit (e94c6101e151) did the work in the right
> place, but the blkfront behavior change commit didn't.
>
> So, I guess below change would fix the issue entirely when applied together
> with this patch. Any opinion, please?
>
>
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index dfae08115450..7d3bde271e69 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -1850,6 +1850,7 @@ static int talk_to_blkback(struct xenbus_device *dev,
> message = "writing protocol";
> goto abort_transaction;
> }
> + info->feature_persistent_parm = feature_persistent;
> err = xenbus_printf(xbt, dev->nodename, "feature-persistent", "%u",
> info->feature_persistent_parm);
> if (err)
> @@ -2284,7 +2285,6 @@ static void blkfront_gather_backend_features(struct blkfront_info *info)
> if (xenbus_read_unsigned(info->xbdev->otherend, "feature-discard", 0))
> blkfront_setup_discard(info);
>
> - info->feature_persistent_parm = feature_persistent;
> if (info->feature_persistent_parm)
> info->feature_persistent =
> !!xenbus_read_unsigned(info->xbdev->otherend,
>
>
> Thanks,
> SJ
>
>
> >
> > > + if (info->feature_persistent_parm)
> > > info->feature_persistent =
> > > !!xenbus_read_unsigned(info->xbdev->otherend,
> > > "feature-persistent", 0);
> > > --
> > > 2.25.1
> > >
> >
next prev parent reply other threads:[~2022-08-26 21:59 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-25 16:15 [PATCH 0/2] xen-blk{front,back}: Advertise feature-persistent as user requested SeongJae Park
2022-08-25 16:15 ` [PATCH 1/2] xen-blkback: " SeongJae Park
2022-08-31 15:47 ` Pratyush Yadav
2022-08-31 16:17 ` SeongJae Park
2022-08-25 16:15 ` [PATCH 2/2] xen-blkfront: " SeongJae Park
2022-08-26 14:26 ` Maximilian Heyne
2022-08-26 21:20 ` SeongJae Park
2022-08-26 21:59 ` SeongJae Park [this message]
2022-08-27 0:27 ` SeongJae Park
2022-08-31 15:50 ` Pratyush Yadav
2022-08-31 16:20 ` SeongJae Park
2022-08-26 7:15 ` [PATCH 0/2] xen-blk{front,back}: " Juergen Gross
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220826215924.50813-1-sj@kernel.org \
--to=sj@kernel.org \
--cc=axboe@kernel.dk \
--cc=jgross@suse.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marmarek@invisiblethingslab.com \
--cc=mheyne@amazon.de \
--cc=roger.pau@citrix.com \
--cc=stable@vger.kernel.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).