lkml.org 
[lkml]   [2018]   [Sep]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [Xen-devel] [PATCH 2/6] xenbus: implement the xenwatch multithreading framework
From
Date
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

\
 
 \ /
  Last update: 2018-09-17 21:59    [W:0.108 / U:0.128 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site