From: Juergen Gross <jgross@suse.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
linux-block@vger.kernel.org
Cc: roger.pau@citrix.com, konrad.wilk@oracle.com, axboe@kernel.dk
Subject: Re: [PATCH] xen/blkfront: correct purging of persistent grants
Date: Fri, 28 Sep 2018 15:52:56 +0200 [thread overview]
Message-ID: <cfebb100-952b-4b86-9b27-222dd89031dd@suse.com> (raw)
In-Reply-To: <b454645f-de15-2912-864e-18f00736013d@oracle.com>
On 28/09/2018 15:33, Boris Ostrovsky wrote:
> On 9/28/18 9:13 AM, Juergen Gross wrote:
>> On 28/09/2018 14:45, Boris Ostrovsky wrote:
>>> On 9/28/18 3:28 AM, Juergen Gross wrote:
>>>> Commit a46b53672b2c2e3770b38a4abf90d16364d2584b ("xen/blkfront: cleanup
>>>> stale persistent grants") introduced a regression as purged persistent
>>>> grants were not pu into the list of free grants again. Correct that.
>>>>
>>>> Signed-off-by: Juergen Gross <jgross@suse.com>
>>>> ---
>>>> drivers/block/xen-blkfront.c | 4 ++--
>>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
>>>> index a71d817e900d..429d20131c7e 100644
>>>> --- a/drivers/block/xen-blkfront.c
>>>> +++ b/drivers/block/xen-blkfront.c
>>>> @@ -2670,8 +2670,8 @@ static void purge_persistent_grants(struct blkfront_info *info)
>>>> list_del(&gnt_list_entry->node);
>>>> gnttab_end_foreign_access(gnt_list_entry->gref, 0, 0UL);
>>>> rinfo->persistent_gnts_c--;
>>>> - __free_page(gnt_list_entry->page);
>>>> - kfree(gnt_list_entry);
>>>> + gnt_list_entry->gref = GRANT_INVALID_REF;
>>>> + list_add_tail(&gnt_list_entry->node, &rinfo->grants);
>>> Sorry, I don't follow this. What is the purpose of removing the grant
>>> from rinfo->grants list with list_del() and then adding it back with
>>> list_add_tail()?
>> The persistent grants are at the list head and the non-persistent ones
>> at the tail.
>
> Oh, I didn't realize that. But isn't that an optimization (and so not
> following this rule should not cause errors)?
In theory: yes.
The persistent grant handling is rather complicated so I'd like to make
sure not to deviate from the common standards.
When I find some time I want to modify the persistent grant handling to
be more explicit and controlled completely by the frontend (within the
backend defined limits, of course). Until then we should try to modify
persistent grants not too much IMO.
Juergen
next prev parent reply other threads:[~2018-09-28 13:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-28 7:28 Juergen Gross
2018-09-28 7:58 ` [Xen-devel] " Alan Robinson
2018-09-28 12:45 ` Boris Ostrovsky
2018-09-28 13:13 ` Juergen Gross
2018-09-28 13:33 ` Boris Ostrovsky
2018-09-28 13:52 ` Juergen Gross [this message]
2018-09-28 14:03 ` Boris Ostrovsky
2018-09-28 15:41 ` Jens Axboe
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=cfebb100-952b-4b86-9b27-222dd89031dd@suse.com \
--to=jgross@suse.com \
--cc=axboe@kernel.dk \
--cc=boris.ostrovsky@oracle.com \
--cc=konrad.wilk@oracle.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=roger.pau@citrix.com \
--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
all inboxes | Powered by JetHome®