Re: [Xen-devel] [PATCH] [XEN] [ACM] [2/2] Restructuring ACM-related code in do_domctl

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

On 22/4/07 18:35, "Stefan Berger" <stefanb@xxxxxxxxxx> wrote:

> At the beginning of do_domctl() there's the call to acm_pre_domctl, which ends up in its callpath in chwall_pre_domain_create to check whether under the current policy the domain is allowed to be created and it grabs the lock to the policy before doing that. 
> At the end of the do_domctl() there's the call to acm_post_domctl, in case everything went fine with creating the domain for example. Here it ends up in its callpath in chwall_post_domain_create where it again grabs the lock to the policy and under the assumption that the policy hasn't changed modifies a counter array (running_types). 
> If the policy is changed in between those calls, i.e. the chinese wall part is changed such that the domain would not be allowed to exist under the new policy, the post-domain-create call would still go through. That's what I want to prevent with a continously-held lock that spans the evaluation at the beginning and the modification of that counter array at the end. 

If you did this with a straightforward domain_create() hook, you could update state at the same time as doing the policy check. Your domain_destroy() hook would be called if the creation subsequently failed to commit. And if the policy changes at any time after the call to your domain_create() hook, you’ve already updated your ACM state so you can see the new domain via some internal structure you presumably maintains, and hence can re-evaluate the decision under the new policy.

In general, keeping checks and state updates together is nice compared with pushing them to pre/post hooks with locks implicitly held across the two. That’s just plain gross imo.

That is, an architecture where you have a ‘pre-doing-stuff’ hook and a ‘pre-destroying-stuff’ hook, where the latter is also called when the doing-stuff action turns out to fail, is nicer than pre/post hooks.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel