All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vincent Hanquez <vincent.hanquez@eu.citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Kamala Narasimhan <kamala.narasimhan@gmail.com>,
	Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Gianni Tedesco <gianni.tedesco@citrix.com>
Subject: Re: libxl: error handling before xenstored runs
Date: Thu, 10 Feb 2011 09:26:15 +0000	[thread overview]
Message-ID: <4D53AF37.9010204@eu.citrix.com> (raw)
In-Reply-To: <1297328120.1047.21.camel@zakaz.uk.xensource.com>

On 10/02/11 08:55, Ian Campbell wrote:
> That's the underlying bug which the heuristic is trying to avoid...
>
> Fundamentally the xs ring protocol is missing any way to tell if someone
> is listening on the other end so you have no choice but to try
> communicating and see if anyone responds.
>
> It's a pretty straightforward bug that the kernel does the waiting to
> see if anyone responds bit with an uninterruptible sleep. I took a quick
> look a little while ago but unfortunately it didn't look straightforward
> to fix on the kernel side :-( I can't remember why though.

For starter, the protocol requires the messages to sit on the ring for a 
underdetermined amount of time (boot watches).

> It might be simpler to support allowing the userspace client to
> explicitly specify a timeout. I'm not sure what the impact on the ring
> is of leaving unconsumed requests on the ring when the other end does
> show up. Presumably the kernel driver just needs to be prepared to
> swallow responses whose target has given up and gone home.

No, the simplest thing to do is to use the socket connection 
exclusively. Just how we're doing it in XCP and XCI.

The protocol is not design to do async either, so leaving unconsumed 
request, could be pretty disastrous if the other end show up. Providing
the kernel doesn't detect it (i don't think it does [1]), it would imply 
spurious reply, for example the previous waiting read on "/abc/def" 
could reply to a next read on "/xyz/123".

> Maybe we should add an explicit ping/pong ring message to the xs ring
> protocol?

And who's going to reply to this if xenstored is missing ? you would 
require the kernel to introspect the messages and reply by itself.

[1] the kernel would be happy to read the previous reply on the ring 
after xenstored has put the actual reply after it, and trigger the 
eventchn. (the kernel could actually check the requestid and see if they 
match, but it doesn't.)

-- 
Vincent

  reply	other threads:[~2011-02-10  9:26 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-09 11:13 libxl: error handling before xenstored runs Christoph Egger
2011-02-09 14:29 ` Kamala Narasimhan
2011-02-09 14:42   ` Christoph Egger
2011-02-09 14:46     ` Kamala Narasimhan
2011-02-09 15:32       ` Christoph Egger
2011-02-09 15:42         ` Kamala Narasimhan
2011-02-09 15:52           ` Christoph Egger
2011-02-09 15:54             ` Christoph Egger
2011-02-09 17:39               ` Gianni Tedesco
2011-02-10  8:55                 ` Ian Campbell
2011-02-10  9:26                   ` Vincent Hanquez [this message]
2011-02-10 11:24                     ` Ian Campbell
2011-02-10 11:32                       ` Christoph Egger
2011-02-10 11:43                         ` Ian Campbell
2011-02-10 12:23                           ` Christoph Egger
2011-02-10 12:42                             ` Ian Jackson
2011-02-10 21:55                       ` Vincent Hanquez
2011-02-11  8:03                         ` Ian Campbell
2011-02-11  9:49                         ` Tim Deegan
2011-02-11 11:16                           ` Vincent Hanquez
2011-02-10 18:30                   ` Gianni Tedesco
2011-02-10 19:33                     ` Ian Jackson

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=4D53AF37.9010204@eu.citrix.com \
    --to=vincent.hanquez@eu.citrix.com \
    --cc=Christoph.Egger@amd.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=gianni.tedesco@citrix.com \
    --cc=kamala.narasimhan@gmail.com \
    --cc=xen-devel@lists.xensource.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.