Messages in this thread | | | Subject | Re: [Xen-devel] [PATCH 2/6] xenbus: implement the xenwatch multithreading framework | From | Boris Ostrovsky <> | Date | Mon, 17 Sep 2018 16:00:19 -0400 |
| |
On 9/16/18 9:48 PM, Dongli Zhang wrote: > Hi Boris, > > On 09/17/2018 05:20 AM, Boris Ostrovsky wrote: >> >> On 9/14/18 3:34 AM, Dongli Zhang wrote: >>> + >>> +/* Running in the context of default xenwatch kthread. */ >>> +void mtwatch_create_domain(domid_t domid) >>> +{ >>> + struct mtwatch_domain *domain; >>> + >>> + if (!domid) { >>> + pr_err("Default xenwatch thread is for dom0\n"); >>> + return; >>> + } >>> + >>> + spin_lock(&mtwatch_info->domain_lock); >>> + >>> + domain = mtwatch_find_domain(domid); >>> + if (domain) { >>> + atomic_inc(&domain->refcnt); >>> + spin_unlock(&mtwatch_info->domain_lock); >>> + return; >>> + } >>> + >>> + domain = kzalloc(sizeof(*domain), GFP_ATOMIC); >> Is there a reason (besides this being done under spinlock) for using GFP_ATOMIC? >> If domain_lock is the only reason I'd probably drop the lock and do GFP_KERNEL. > spin_lock is the reason. > > Would you like to switch to a mutex here?
I'd use mutex.
-boris
| |