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:30:16 +0200 [thread overview]
Message-ID: <5243FEA8.2090406@citrix.com> (raw)
In-Reply-To: <1380187486.29483.26.camel@kazak.uk.xensource.com>
On 26/09/13 11:24, Ian Campbell wrote:
> On Thu, 2013-09-26 at 11:20 +0200, Roger Pau Monné wrote:
>> 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.
>
> Please do.
>
> Can you also enumerate the intended permissions for each bit
> of /local/domain/<domid>/backends/<type>/<guest_domid>/<id>
>
> I think you are changing the perms of "backends" onwards, but is that
> really necessary? The backend should be cleaning up <id>, which needs
> write perms for <guest_domid> but could the toolstack not do the rest?
Yes, since I'm going to change the patch to syncronize with the
toolstack domain, it can do the rest of the cleaning on behalf of the
guest (the guest will only remove
/local/domain/<domid>/backends/<type>/<guest_domid>/<id> and there won't
be a need to change any permissions).
_______________________________________________
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:30 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é
2013-09-26 9:24 ` Ian Campbell
2013-09-26 9:30 ` Roger Pau Monné [this message]
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=5243FEA8.2090406@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).