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

Re: [Xen-devel] [PATCH] pvcalls-front: Use GFP_ATOMIC under spin_lock



OK, we'll send a v2 patch soon.
Thank you.

Regards,
Wen
------------------Original Mail------------------
Sender: JuergenGross <jgross@xxxxxxxx>
To: wen yang10156314;boris.ostrovsky@xxxxxxxxxx 
<boris.ostrovsky@xxxxxxxxxx>sstabellini@xxxxxxxxxx <sstabellini@xxxxxxxxxx>
CC: xen-devel@xxxxxxxxxxxxxxxxxxxx 
<xen-devel@xxxxxxxxxxxxxxxxxxxx>linux-kernel@xxxxxxxxxxxxxxx 
<linux-kernel@xxxxxxxxxxxxxxx>zhong weidong10001088;Julia Lawall 
<julia.lawall@xxxxxxx>
Date: 2018/11/30 01:01
Subject: Re: [PATCH] pvcalls-front: Use GFP_ATOMIC under spin_lock
On 29/11/2018 13:01, Wen Yang wrote:
> The problem is that we call this with a spin lock held.
> The call tree is:
> pvcalls_front_accept() holds bedata->socket_lock.
>     -> create_active()
>         -> __get_free_pages() uses GFP_KERNEL
>
> The create_active() function is only called from pvcalls_front_accept()
> with a spin_lock held, The allocation is not allowed to sleep and
> GFP_KERNEL is not sufficient, it has to be ATOMIC.

I'd rather have a function doing the allocations which is called
outside the lock and either passing the allocated data to
create_active() or hook it into map in the allocation function.


Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

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