From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel@lists.xenproject.org, Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [PATCH RFC 06/12] libxl: set correct permissions for the full backend path
Date: Thu, 26 Sep 2013 11:20:32 +0200 [thread overview]
Message-ID: <5243FC60.9040004@citrix.com> (raw)
In-Reply-To: <1380122323.4910.22.camel@kazak.uk.xensource.com>
On 25/09/13 17:18, Ian Campbell wrote:
> On Wed, 2013-09-25 at 17:10 +0200, Roger Pau Monné wrote:
>> On 25/09/13 17:00, Ian Campbell wrote:
>>> On Wed, 2013-09-25 at 16:02 +0200, Roger Pau Monné wrote:
>>>> On 25/09/13 15:57, Ian Campbell wrote:
>>>>> On Mon, 2013-09-23 at 12:30 +0200, Roger Pau Monne wrote:
>>>>>> The backend path should be fully owned by the domain where it resides.
>>>>>
>>>>> I can see why /local/domain/<domid>backends/<type>/<id> would need to be
>>>>> owned by the backend dom, but why
>>>>> do /local/domain/<domid>backends/<type>/, /local/domain/<domid>backends/, etc need to be?
>>>>
>>>> The path /local/domain/<domid>backends/<type>/<guest_domid>/<id> is
>>>> already owned by the driver domain, the problem is that if the driver
>>>> domain has to perform the clean up of this path it should be able to
>>>> fully remove it, otherwise we are leaving empty directories around in
>>>> xenstore (backend/<type>/<guest_domid> and so).
>>>>
>>>> And performing the clean up from the toolstack domain is not that easy,
>>>> we will have to add a way to signal the toolstack domain that the driver
>>>> domain has finished the disconnection and the directory can be cleaned.
>>>
>>> Don't we need that anyway so that the toolstack domain can synchronise
>>> the end of the asynchronous op which is the remove?
>>
>> Not really IMHO, the toolstack waits for the device frontend to
>> disconnect and then it removes the frontend xenstore entries. Then (or
>> in parallel) the domain that's handling the backend should deal with the
>> disconnection of the backend and perform any necessary actions and clean
>> up the backend xenstore entries.
>
> So e.g. xl destroy can potentially return while the backend is still
> closing down? That would mean it might fail to reboot the guest, because
> the block device in the driver domain is still busy.
True, since we don't synchronize with the toolstack there's a small
window were a new domain could be created before the driver domain
hasn't finished unplugging. This is a problem already with current udev
implementation, but I think we can solve this by adding a watch in the
toolstack that waits for the backend path to be destroyed (when the
backend is on a driver domain, of course).
I will expand this patch to include the above mentioned check.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2013-09-26 9:20 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-23 10:30 [PATCH RFC 00/12] libxl: add driver domain backend daemon Roger Pau Monne
2013-09-23 10:30 ` [PATCH RFC 01/12] libxl/hotplug: add support for getting domid Roger Pau Monne
2013-09-25 13:50 ` Ian Campbell
2013-09-23 10:30 ` [PATCH RFC 02/12] libxl: remove unneeded libxl_domain_info in wait_device_connection Roger Pau Monne
2013-09-25 13:51 ` Ian Campbell
2013-09-23 10:30 ` [PATCH RFC 03/12] libxl: make hotplug execution conditional on backend_domid == domid Roger Pau Monne
2013-09-25 13:52 ` Ian Campbell
2013-09-23 10:30 ` [PATCH RFC 04/12] libxl: create a local xenstore libxl and device-model dir for guests Roger Pau Monne
2013-09-25 13:48 ` Ian Campbell
2013-09-26 9:27 ` Roger Pau Monné
2013-09-26 9:39 ` Ian Campbell
2013-09-26 9:57 ` Roger Pau Monné
2013-09-26 10:15 ` Ian Campbell
2013-09-26 10:20 ` Roger Pau Monné
2013-09-26 10:26 ` Ian Campbell
2013-09-23 10:30 ` [PATCH RFC 05/12] libxl: don't remove device backend path if not local Roger Pau Monne
2013-09-25 13:54 ` Ian Campbell
2013-09-23 10:30 ` [PATCH RFC 06/12] libxl: set correct permissions for the full backend path Roger Pau Monne
2013-09-25 13:57 ` Ian Campbell
2013-09-25 14:02 ` Roger Pau Monné
2013-09-25 15:00 ` Ian Campbell
2013-09-25 15:10 ` Roger Pau Monné
2013-09-25 15:18 ` Ian Campbell
2013-09-26 9:20 ` Roger Pau Monné [this message]
2013-09-26 9:24 ` Ian Campbell
2013-09-26 9:30 ` Roger Pau Monné
2013-09-26 9:39 ` Ian Campbell
2013-09-23 10:30 ` [PATCH RFC 07/12] libxl: remove the Qemu bodge for driver domain devices Roger Pau Monne
2013-09-23 10:30 ` [PATCH RFC 08/12] libxl: don't launch Qemu on Dom0 for Qdisk devices on driver domains Roger Pau Monne
2013-09-25 15:06 ` Ian Campbell
2013-09-25 15:13 ` Roger Pau Monné
2013-09-23 10:30 ` [PATCH RFC 09/12] libxl: add Qdisk backend launch helper Roger Pau Monne
2013-09-23 10:30 ` [PATCH RFC 10/12] xl: put daemonize code in it's own function Roger Pau Monne
2013-09-23 10:30 ` [PATCH RFC 11/12] libxl: revert 326a7b74 Roger Pau Monne
2013-09-23 10:30 ` [PATCH RFC 12/12] libxl: add device backend listener in order to launch backends Roger Pau Monne
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=5243FC60.9040004@citrix.com \
--to=roger.pau@citrix.com \
--cc=Ian.Campbell@citrix.com \
--cc=Ian.Jackson@eu.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;
as well as URLs for NNTP newsgroup(s).