[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?
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 mailing list