[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: Stefan Berger <stefanb@xxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
  • Date: Sun, 22 Apr 2007 11:07:05 +0100
  • Delivery-date: Sun, 22 Apr 2007 03:04:18 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AceExfqIOSY4wvC5EduDnwAWy6hiGQ==
  • Thread-topic: [Xen-devel] [PATCH] [XEN] [ACM] [2/2] Restructuring ACM-related code in do_domctl

I think that relying on domctl wrapper functions to do necessary label
bookkeeping on domain create/destroy is making things more complicated than
they need to be. Wrapper functions are obviously the right answer for most
ACM functions (since they are allow/deny checks, external to the core logic
of the operation being checked), but in the case of domain create/destroy
ACM is more part of the process.

So, how about having functions: domain_acm_create() and
domain_acm_destroy()? The former would be called from domain_create(), the
latter from the error path of domain_create() and from domain_destroy().

You can then have appropriate critical regions *within* those functions (not
across them) that you synchronise against when relabelling the world. And
you shouldn't then need to modify do_domctl() at all?

 -- Keir

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

> This patch restructures the ACM-related code in the do_domctl() function
> so that the lock to the policy can be fetched in the individual
> operations, i.e., XEN_DOMCTL_createdomain, and the pair of locking
> functions acm_rlock_policy()/acm_runlock_policy() don't take the
> function parameter anymore.
> 
> Sign-off-by: Stefan Berger <stefanb@xxxxxxxxxx>
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.