This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [Patch] linux: avoid kmalloc while disabling interrupts

To: "Akio Takebe" <takebe_akio@xxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [Patch] linux: avoid kmalloc while disabling interrupts
From: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Date: Tue, 09 Sep 2008 09:22:46 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 09 Sep 2008 01:22:44 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <48C628BC.8090805@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <48C628BC.8090805@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> Akio Takebe <takebe_akio@xxxxxxxxxxxxxx> 09.09.08 09:41 >>>
>We should avoid using kmalloc while interrupts is disabled.
>kmalloc may sleep.
>Signed-off-by: Akio Takebe <takebe_akio@xxxxxxxxxxxxxx>

I was under the impression that this is why the code uses GFP_ATOMIC.

Also, doesn't that patch introduce new problems, in dropping the lock
intermediately and then adding entries to lists without checking for
already existing entries again? I'd suppose if you want the allocations
to be done outside of the lock, you should do them in advance
(regardless of whether you'll actually need them) and free the memory
after dropping the lock if the entries weren't really inserted anywhere.


Xen-devel mailing list