Re: [Xen-devel] preparing for 4.2.2 and 4.1.5

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Thu, 28 Feb 2013, Jan Beulich wrote:
> >>> On 28.02.13 at 10:21, Alex Bligh <alex@xxxxxxxxxxx> wrote:
> > Jan,
> > 
> > --On 28 February 2013 07:31:32 +0000 Jan Beulich <JBeulich@xxxxxxxx> wrote:
> > 
> >>>>> On 27.02.13 at 19:44, Alex Bligh <alex@xxxxxxxxxxx> wrote:
> >>> --On 27 February 2013 16:12:57 +0000 Jan Beulich <JBeulich@xxxxxxxx>
> >>> wrote:
> >>>> Aiming at a release towards the end of March, I'd like to cut RC1-s
> >>>> at the beginning of next week.
> >>>
> >>> I'd ask for the 'don't use O_DIRECT change'. I realise I owe the list
> >>> a blktrace.
> >>
> >> To me, the title you mention means nothing. It being on the tools
> >> side, it would be Ian anyway to take care of this, but can't you be
> >> a bit more specific and indicate which changeset/commit you're
> >> talking of? As well as reasoning why it would be needed (or at
> >> least desirable) to have on either or both trees?
> > 
> > See this message and the surrounding thread:
> >   http://markmail.org/message/iy32akdzmbjo7uiz 
> > 
> > In essence any domU PV disk usage backended onto something that uses TCP
> > (e.g. iSCSI, NFS) in dom0 has the potential to crash dom0. We can replicate
> > this 100%. The root cause is a very-hard-to-fix skb refcount problem
> > in the kernel, but the obvious fix is to disable O_DIRECT in qemu's
> > xendisk driver. People seemed generally happy with this provided the
> > barriers get through (which I need to demonstrate).
> 
> Oh, that would actually be Stefano, not Ian then.
> 
> And it doesn't look like you're asking for a backport - neither
> upstream qemu nor either of our trees appears to have the
> suggested change yet. If the change doesn't go into any of
> these, there's no way for it to go into a stable release.

Right, as written in http://markmail.org/message/iy32akdzmbjo7uiz, I
agree that we should disable O_DIRECT, once you have proven that the
barriers and flushes are handled correctly (henceforth we wouldn't
cause data corruptions).

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel