All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joe Jin <joe.jin@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Frank Blaschka <frank.blaschka@de.ibm.com>,
	zheng.x.li@oracle.com, Jan Beulich <JBeulich@suse.com>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	Xen Devel <xen-devel@lists.xen.org>,
	Alex Bligh <alex@alex.org.uk>,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: kernel panic in skb_copy_bits
Date: Thu, 04 Jul 2013 16:55:50 +0800	[thread overview]
Message-ID: <51D53896.1060405__21487.2712073431$1372928282$gmane$org@oracle.com> (raw)
In-Reply-To: <1372666283.14691.8.camel@zakaz.uk.xensource.com>

On 07/01/13 16:11, Ian Campbell wrote:
> On Mon, 2013-07-01 at 11:18 +0800, Joe Jin wrote:
>>> A workaround is to turn off O_DIRECT use by Xen as that ensures
>>> the pages are copied. Xen 4.3 does this by default.
>>>
>>> I believe fixes for this are in 4.3 and 4.2.2 if using the
>>> qemu upstream DM. Note these aren't real fixes, just a workaround
>>> of a kernel bug.
>>
>> The guest is pvm, and disk model is xvbd, guest config file as below:
> 
> Do you know which disk backend? The workaround Alex refers to went into
> qdisk but I think blkback could still suffer from a variant of the
> retransmit issue if you run it over iSCSI.
> 
>>> To fix on a local build of xen you will need something like this:
>>> https://github.com/abligh/qemu-upstream-4.2-testing/commit/9a97c011e1a682eed9bc7195a25349eaf23ff3f9
>>> and something like this (NB: obviously insert your own git
>>> repo and commit numbers)
>>> https://github.com/abligh/xen/commit/f5c344afac96ced8b980b9659fb3e81c4a0db5ca
>>>
>>
>> I think this only for pvhvm/hvm?
> 
> No, the underlying issue affects any PV device which is run over a
> network protocol (NFS, iSCSI etc). In effect a delayed retransmit can
> cross over the deayed ack and cause I/O to be completed while
> retransmits are pending, such as is described in
> http://www.spinics.net/lists/linux-nfs/msg34913.html (the original NFS
> variant). The problem is that because Xen PV drivers often unmap the
> page on I/O completion you get a crash (page fault) on the retransmit.
> 

Can we do it by remember grant page refcount when mapping, and when unmap
check if page refcount as same as mapping?  This change will limited in
xen-blkback.

Another way is add new page flag like PG_send, when sendpage() be called,
set the bit, when page be put, clear the bit. Then xen-blkback can wait
on the pagequeue.

Thanks,
Joe

> The issue also affects native but in that case the symptom is "just" a
> corrupt packet on the wire. I tried to address this with my "skb
> destructor" series but unfortunately I got bogged down on the details,
> then I had to take time out to look into some other stuff and never
> managed to get back into it. I'd be very grateful if there was someone
> who could pick up that work (Alex gave some useful references in another
> reply to this thread)
> 
> Some PV disk backends (e.g. blktap2) have worked around this by using
> grant copy instead of grant map, others (e.g. qdisk) have disabled
> O_DIRECT so that the pages are copied into the dom0 page cache and
> transmitted from there.
> 
> We were discussing recently the possibility of mapping all ballooned out
> pages to a single read-only scratch page instead of leaving them empty
> in the page tables, this would cause the Xen case to revert to the
> native case. I think Thanos was going to take a look into this.
> 
> Ian.
> 


-- 
Oracle <http://www.oracle.com>
Joe Jin | Software Development Senior Manager | +8610.6106.5624
ORACLE | Linux and Virtualization
No. 24 Zhongguancun Software Park, Haidian District | 100193 Beijing 

  parent reply	other threads:[~2013-07-04  8:55 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-27  2:58 kernel panic in skb_copy_bits Joe Jin
2013-06-27  2:58 ` Joe Jin
2013-06-27  5:31 ` Eric Dumazet
2013-06-27  5:31   ` Eric Dumazet
2013-06-27  7:15   ` Joe Jin
2013-06-27  7:15     ` Joe Jin
2013-06-28  4:17   ` Joe Jin
2013-06-28  4:17     ` Joe Jin
2013-06-28  6:52     ` Eric Dumazet
2013-06-28  6:52       ` Eric Dumazet
2013-06-28  9:37       ` Eric Dumazet
2013-06-28  9:37       ` Eric Dumazet
2013-06-28 11:33         ` Joe Jin
2013-06-28 11:33         ` Joe Jin
2013-06-28 23:36         ` Joe Jin
2013-06-28 23:36           ` Joe Jin
2013-06-29  7:04           ` Eric Dumazet
2013-06-29  7:04           ` Eric Dumazet
2013-06-29  7:20           ` Eric Dumazet
2013-06-29  7:20           ` Eric Dumazet
2013-06-29  7:20             ` Eric Dumazet
2013-06-29 16:11             ` Ben Greear
2013-06-29 16:11             ` Ben Greear
2013-06-29 16:11               ` Ben Greear
2013-06-29 16:26               ` Eric Dumazet
2013-06-29 16:31                 ` Ben Greear
2013-06-29 16:31                 ` Ben Greear
2013-06-29 16:26               ` Eric Dumazet
2013-06-30  0:26             ` Joe Jin
2013-06-30  0:26               ` Joe Jin
2013-06-30  7:50               ` Eric Dumazet
2013-06-30  7:50               ` Eric Dumazet
2013-06-30  0:26             ` Joe Jin
2013-06-28 23:36         ` Joe Jin
2013-07-01 20:36         ` David Miller
2013-07-01 20:36         ` David Miller
2013-06-28  6:52     ` Eric Dumazet
2013-06-30  9:13     ` Alex Bligh
2013-06-30  9:13       ` Alex Bligh
2013-06-30  9:35       ` Alex Bligh
2013-06-30  9:35       ` Alex Bligh
2013-07-01  3:18       ` Joe Jin
2013-07-01  8:11         ` Ian Campbell
2013-07-01  8:11         ` Ian Campbell
2013-07-01 13:00           ` Joe Jin
2013-07-01 13:00           ` Joe Jin
2013-07-04  8:55           ` Joe Jin [this message]
2013-07-04  8:55           ` Joe Jin
2013-07-04  8:59             ` Ian Campbell
2013-07-04  8:59             ` Ian Campbell
2013-07-04  9:34               ` Eric Dumazet
2013-07-04  9:34               ` Eric Dumazet
2013-07-04  9:52                 ` Ian Campbell
2013-07-04  9:52                 ` Ian Campbell
2013-07-04 10:12                   ` Eric Dumazet
2013-07-04 10:12                   ` Eric Dumazet
2013-07-04 12:57                     ` Alex Bligh
2013-07-04 12:57                     ` Alex Bligh
2013-07-04 21:32                     ` David Miller
2013-07-04 21:32                     ` David Miller
2013-07-01  8:29         ` Alex Bligh
2013-07-01  8:29         ` Alex Bligh
2013-07-01  3:18       ` Joe Jin
2013-06-28  4:17   ` Joe Jin

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='51D53896.1060405__21487.2712073431$1372928282$gmane$org@oracle.com' \
    --to=joe.jin@oracle.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=alex@alex.org.uk \
    --cc=davem@davemloft.net \
    --cc=eric.dumazet@gmail.com \
    --cc=frank.blaschka@de.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=xen-devel@lists.xen.org \
    --cc=zheng.x.li@oracle.com \
    /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.