From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Bob Liu <bob.liu@oracle.com>, David Vrabel <david.vrabel@citrix.com>
Cc: xen-devel@lists.xenproject.org,
Boris Ostrovsky <boris.ostrovsky@oracle.com>,
Jenny Herbert <jennifer.herbert@citrix.com>
Subject: Re: [PATCHv5 12/14] xen-blkback: safely unmap grants in case they are still in use
Date: Thu, 12 Mar 2015 12:30:49 +0900 [thread overview]
Message-ID: <55010869.6000403@citrix.com> (raw)
In-Reply-To: <5500D90A.6080006@oracle.com>
Hello,
El 12/03/15 a les 9.08, Bob Liu ha escrit:
>
> On 03/09/2015 07:02 PM, David Vrabel wrote:
>> On 09/03/15 10:51, Bob Liu wrote:
>>>
>>> On 03/09/2015 05:30 PM, David Vrabel wrote:
>>>> On 09/03/15 09:09, Bob Liu wrote:
>>>>> Hi David,
>>>>>
>>>>> Recently I met an issue which is likely related with this patch. It
>>>>> happened when running block benchmark on domU, the backend was an iSCSI
>>>>> disk connected to dom0. I got below panic at put_page_testzero() on
>>>>> dom0, at that time the ixgbe network card was freeing skb pages in
>>>>> __skb_frag_unref() but the page->_count was already 0.
>>>>> Do you think is it possiable that page was already freed by blkback?
>>>>
>>>> It's possible, but in this case I think the blkback device must have
>>>> been destroyed for this to have happened, because blkback doesn't free
>>>> the pages until it is destroyed.
>>>>
>>>
>>> Sorry, I didn't get the point here, doesn't bio_complete free pages?
>>> E.g.
>>> __end_block_io_op() > xen_blkbk_unmap_and_respond() > put_free_pages()
>>> Then shrink_free_pagepool() free the page finally.
>>
>> Ug. That's all the persistent grant stuff I'm not very familiar with.
>> Perhaps Roger can comment?
>>
>
> Well, I think I may figure out this issue but haven't confirmed yet.
>
> In purge_persistent_gnt() > unmap_purged_grants(), we should also change
> to use gnttab_unmap_refs_async().
Good catch! Yes xen_blkbk_unmap_purged_grants is not using the new
unmap interface. I have a patch that should fix this, but right now I'm
not even able to compile test it. If you want to give it a spin:
diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
index 2a04d34..cd1517f 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -327,9 +327,19 @@ void xen_blkbk_unmap_purged_grants(struct work_struct *work)
struct gnttab_unmap_grant_ref unmap[BLKIF_MAX_SEGMENTS_PER_REQUEST];
struct page *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
struct persistent_gnt *persistent_gnt;
- int ret, segs_to_unmap = 0;
+ int segs_to_unmap = 0;
+ struct gntab_unmap_queue_data unmap_data;
+ struct completion unmap_completion;
struct xen_blkif *blkif = container_of(work, typeof(*blkif), persistent_purge_work);
+ init_completion(&unmap_completion);
+
+ unmap_data.data = &unmap_completion;
+ unmap_data.done = &free_persistent_gnts_unmap_callback;
+ unmap_data.pages = pages;
+ unmap_data.unmap_ops = unmap;
+ unmap_data.kunmap_ops = NULL;
+
while(!list_empty(&blkif->persistent_purge_list)) {
persistent_gnt = list_first_entry(&blkif->persistent_purge_list,
struct persistent_gnt,
@@ -343,20 +353,19 @@ void xen_blkbk_unmap_purged_grants(struct work_struct *work)
pages[segs_to_unmap] = persistent_gnt->page;
- if (++segs_to_unmap == BLKIF_MAX_SEGMENTS_PER_REQUEST) {
- ret = gnttab_unmap_refs(unmap, NULL, pages,
- segs_to_unmap);
- BUG_ON(ret);
+ if (++segs_to_unmap == BLKIF_MAX_SEGMENTS_PER_REQUEST ||
+ list_empty(&blkif->persistent_purge_list)) {
+
+ unmap_data.count = segs_to_unmap;
+ gnttab_unmap_refs_async(&unmap_data);
+ wait_for_completion(&unmap_completion);
+
put_free_pages(blkif, pages, segs_to_unmap);
segs_to_unmap = 0;
}
kfree(persistent_gnt);
}
- if (segs_to_unmap > 0) {
- ret = gnttab_unmap_refs(unmap, NULL, pages, segs_to_unmap);
- BUG_ON(ret);
- put_free_pages(blkif, pages, segs_to_unmap);
- }
+ BUG_ON(segs_to_unmap != 0);
}
static void purge_persistent_gnt(struct xen_blkif *blkif)
next prev parent reply other threads:[~2015-03-12 3:31 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-27 16:44 [PATCHv5 00/14] xen: fix many long-standing grant mapping bugs David Vrabel
2015-01-27 16:44 ` [PATCHv5 01/14] mm: provide a find_special_page vma operation David Vrabel
2015-01-27 16:44 ` [PATCHv5 02/14] mm: add 'foreign' alias for the 'pinned' page flag David Vrabel
2015-01-27 16:44 ` [PATCHv5 03/14] xen/grant-table: pre-populate kernel unmap ops for xen_gnttab_unmap_refs() David Vrabel
2015-01-28 12:33 ` Stefano Stabellini
2015-01-27 16:44 ` [PATCHv5 04/14] xen: remove scratch frames for ballooned pages and m2p override David Vrabel
2015-01-28 12:35 ` Stefano Stabellini
2015-01-27 16:44 ` [PATCHv5 05/14] x86/xen: require ballooned pages for grant maps David Vrabel
2015-01-27 16:44 ` [PATCHv5 06/14] xen/grant-table: add helpers for allocating pages David Vrabel
2015-01-27 16:44 ` [PATCHv5 07/14] xen: mark grant mapped pages as foreign David Vrabel
2015-01-27 16:44 ` [PATCHv5 08/14] xen-netback: use foreign page information from the pages themselves David Vrabel
2015-01-27 16:44 ` [PATCHv5 09/14] xen/grant-table: add a mechanism to safely unmap pages that are in use David Vrabel
2015-01-27 16:44 ` [PATCHv5 10/14] xen/gntdev: convert priv->lock to a mutex David Vrabel
2015-01-27 16:44 ` [PATCHv5 11/14] xen/gntdev: safely unmap grants in case they are still in use David Vrabel
2015-01-27 16:44 ` [PATCHv5 12/14] xen-blkback: " David Vrabel
2015-03-09 9:09 ` Bob Liu
2015-03-09 9:30 ` David Vrabel
2015-03-09 10:51 ` Bob Liu
2015-03-09 11:02 ` David Vrabel
2015-03-09 11:22 ` Roger Pau Monné
2015-03-09 12:36 ` Bob Liu
2015-03-12 0:08 ` Bob Liu
2015-03-12 3:30 ` Roger Pau Monné [this message]
2015-03-12 18:25 ` David Vrabel
2015-03-13 0:43 ` Bob Liu
2015-01-27 16:44 ` [PATCHv5 13/14] xen/gntdev: mark userspace PTEs as special on x86 PV guests David Vrabel
2015-01-28 12:37 ` Stefano Stabellini
2015-01-27 16:44 ` [PATCHv5 14/14] xen/gntdev: provide find_special_page VMA operation David Vrabel
2015-01-28 14:15 ` [PATCHv5 00/14] xen: fix many long-standing grant mapping bugs David Vrabel
2015-01-30 21:35 ` Konrad Rzeszutek Wilk
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=55010869.6000403@citrix.com \
--to=roger.pau@citrix.com \
--cc=bob.liu@oracle.com \
--cc=boris.ostrovsky@oracle.com \
--cc=david.vrabel@citrix.com \
--cc=jennifer.herbert@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.