Skip to contentSkip to conversation

mvumi: GFP_KERNEL under spin lock

bug report New Dan Carpenter 1 participant 4 messages Aug 14, 2012 – Sep 29, 2012

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

Hello Jianyun Li,

The patch f0c568a478f0: "[SCSI] mvumi: Add Marvell UMI driver" from May 11, 2011, leads to the following warning:
drivers/scsi/mvumi.c:121 mvumi_alloc_mem_resource()
error: scheduling with locks held: 'spin_lock:host_lock'

The problem is that we do a couple GPF_KERNEL allocations in mvumi_alloc_mem_resource() and this static analysis program sees a path where that function is called with spin_locks held.

mvumi_isr_handler() <- takes a spin lock
-> mvumi_handshake()
-> mvumi_init_data()

      -> mvumi_alloc_mem_resource() <- GFP_KERNEL

The IRQ handler does print a warning before calling mvumi_handshake() so it seems like this path doesn't get exercised very much.

regards,
dan carpenter

#1 lore raw

Whatever happened with this? You could just change the GFP_KERNEL to GFP_ATOMIC.

regards,
dan carpenter

Quoted 27 lines · Dan Carpenter

Hello Jianyun Li,

The patch f0c568a478f0: "[SCSI] mvumi: Add Marvell UMI driver" from May 11, 2011, leads to the following warning:
drivers/scsi/mvumi.c:121 mvumi_alloc_mem_resource()
error: scheduling with locks held: 'spin_lock:host_lock'

The problem is that we do a couple GPF_KERNEL allocations in mvumi_alloc_mem_resource() and this static analysis program sees a path where that function is called with spin_locks held.

mvumi_isr_handler() <- takes a spin lock
-> mvumi_handshake()
-> mvumi_init_data()

      -> mvumi_alloc_mem_resource() <- GFP_KERNEL

The IRQ handler does print a warning before calling mvumi_handshake() so it seems like this path doesn't get exercised very much.

regards,
dan carpenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

#2 lore raw
Quoted 3 lines · Dan Carpenter

Whatever happened with this? You could just change the GFP_KERNEL to GFP_ATOMIC.

Ah, that email address is dead is what happened. I'll send a patch that changes this to GFP_ATOMIC.

regards,
dan carpenter

#3 lore raw

PATCH 1/1 mvumi: use GFP_ATOMIC under spin lock

In reply to Dan Carpenter

This is called from the interrupt handler and with spin_locks held. Use GFP_ATOMIC. The call tree looks like:
mvumi_isr_handler() <- takes a spin lock
-> mvumi_handshake()

     -> mvumi_init_data()
        -> mvumi_alloc_mem_resource() <- GFP_KERNEL
drivers/scsi/mvumi.c +2 -2
index 783edc7..5ad8da4 100644
@@ -118,7 +118,7 @@ static int mvumi_map_pci_addr(struct pci_dev *dev, void **addr_array)
 static struct mvumi_res *mvumi_alloc_mem_resource(struct mvumi_hba *mhba,
 				enum resource_type type, unsigned int size)
 {
-	struct mvumi_res *res = kzalloc(sizeof(*res), GFP_KERNEL);
+	struct mvumi_res *res = kzalloc(sizeof(*res), GFP_ATOMIC);
 
 	if (!res) {
 		dev_err(&mhba->pdev->dev,
@@ -128,7 +128,7 @@ static struct mvumi_res *mvumi_alloc_mem_resource(struct mvumi_hba *mhba,
 
 	switch (type) {
 	case RESOURCE_CACHED_MEMORY:
-		res->virt_addr = kzalloc(size, GFP_KERNEL);
+		res->virt_addr = kzalloc(size, GFP_ATOMIC);
 		if (!res->virt_addr) {
 			dev_err(&mhba->pdev->dev,
 				"unable to allocate memory,size = %d.\n", size);