[Patch] linux: avoid kmalloc while disabling interrupts

[Patch] linux: avoid kmalloc while disabling interrupts

[Akio Takebe]

[-- Attachment #1: Type: text/plain, Size: 169 bytes --]

Hi,

We should avoid using kmalloc while interrupts is disabled.
kmalloc may sleep.

Signed-off-by: Akio Takebe <takebe_akio@jp.fujitsu.com>

Best Regards,

Akio Takebe

[-- Attachment #2: avoid_kmalloc_while_disabling_interrupts.patch --]
[-- Type: text/x-diff, Size: 1799 bytes --]

diff -r e86f9e05144a drivers/xen/pciback/controller.c
--- a/drivers/xen/pciback/controller.c	Mon Sep 08 14:02:13 2008 +0100
+++ b/drivers/xen/pciback/controller.c	Tue Sep 09 16:28:20 2008 +0900
@@ -101,15 +101,15 @@
 	unsigned long flags;
 	int ret = 0, found = 0;
 
+	/* Look to see if we already have a domain:bus for this controller */
 	spin_lock_irqsave(&dev_data->lock, flags);
-
-	/* Look to see if we already have a domain:bus for this controller */
 	list_for_each_entry(cntrl_entry, &dev_data->list, list) {
 		if (cntrl_entry->controller == dev_controller) {
 			found = 1;
 			break;
 		}
 	}
+	spin_unlock_irqrestore(&dev_data->lock, flags);
 
 	if (!found) {
 		cntrl_entry = kmalloc(sizeof(*cntrl_entry), GFP_ATOMIC);
@@ -128,9 +128,10 @@
 			dev_data->next_bus = 0;
 		}
 
+		spin_lock_irqsave(&dev_data->lock, flags);
 		INIT_LIST_HEAD(&cntrl_entry->dev_list);
-
 		list_add_tail(&cntrl_entry->list, &dev_data->list);
+		spin_unlock_irqrestore(&dev_data->lock, flags);
 	}
 
 	if (PCI_SLOT(cntrl_entry->next_devfn) > PCI_MAX_SLOTS) {
@@ -149,24 +150,24 @@
 
 	dev_entry = kmalloc(sizeof(*dev_entry), GFP_ATOMIC);
 	if (!dev_entry) {
+		spin_lock_irqsave(&dev_data->lock, flags);
 		if (list_empty(&cntrl_entry->dev_list)) {
 			list_del(&cntrl_entry->list);
 			kfree(cntrl_entry);
 		}
 		ret = -ENOMEM;
+		spin_unlock_irqrestore(&dev_data->lock, flags);
 		goto out;
 	}
 
 	dev_entry->dev = dev;
 	dev_entry->devfn = cntrl_entry->next_devfn;
 
+	spin_lock_irqsave(&dev_data->lock, flags);
 	list_add_tail(&dev_entry->list, &cntrl_entry->dev_list);
-
 	cntrl_entry->next_devfn += PCI_DEVFN(1, 0);
-
+	spin_unlock_irqrestore(&dev_data->lock, flags);
 out:
-	spin_unlock_irqrestore(&dev_data->lock, flags);
-
 	/* TODO: Publish virtual domain:bus:slot.func here. */
 
 	return ret;

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: [Patch] linux: avoid kmalloc while disabling interrupts

[Akio Takebe]

Hi,

Sorry, the kmallocs are GFP_ATOMIC.
So please ignore the patch.

Best Regards,

Akio Takebe

Akio Takebe wrote:
> Hi,
> 
> We should avoid using kmalloc while interrupts is disabled.
> kmalloc may sleep.
> 
> Signed-off-by: Akio Takebe <takebe_akio@jp.fujitsu.com>
> 
> Best Regards,
> 
> Akio Takebe
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: [Patch] linux: avoid kmalloc while disabling interrupts

[Jan Beulich]

>>> Akio Takebe <takebe_akio@jp.fujitsu.com> 09.09.08 09:41 >>>
>We should avoid using kmalloc while interrupts is disabled.
>kmalloc may sleep.
>
>Signed-off-by: Akio Takebe <takebe_akio@jp.fujitsu.com>

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.

Jan

Re: [Patch] linux: avoid kmalloc while disabling interrupts

[Akio Takebe]

Jan Beulich wrote:
>>>> Akio Takebe <takebe_akio@jp.fujitsu.com> 09.09.08 09:41 >>>
>> We should avoid using kmalloc while interrupts is disabled.
>> kmalloc may sleep.
>>
>> Signed-off-by: Akio Takebe <takebe_akio@jp.fujitsu.com>
> 
> 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.
> 
Sorry for my confusion.
As you said, it's my mistake.

Best Regards,

Akio Takebe