[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH RFC 06/12] libxl: set correct permissions for the full backend path
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? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |