[openib-general] [Andrew Morton] inappropriate use of in_atomic()

Roland Dreier roland at topspin.com
Fri Mar 11 13:07:45 PST 2005


Does anyone have a patch that they would prefer to this solution
(unconditionally use GFP_ATOMIC)?  If not I'll send this upstream so
that we at least don't have the potential for deadlock with
CONFIG_PREEMPT=n.  We can always update the API to pass in a gfp_mask
later, if this causes problems.

 - R.

Here's the diff I have:

Index: infiniband/core/mad.c
===================================================================
--- infiniband/core/mad.c	(revision 1975)
+++ infiniband/core/mad.c	(working copy)
@@ -666,11 +666,7 @@ static int handle_outgoing_dr_smp(struct
 	if (!ret || !device->process_mad)
 		goto out;
 
-	if (in_atomic() || irqs_disabled())
-		alloc_flags = GFP_ATOMIC;
-	else
-		alloc_flags = GFP_KERNEL;
-	local = kmalloc(sizeof *local, alloc_flags);
+	local = kmalloc(sizeof *local, GFP_ATOMIC);
 	if (!local) {
 		ret = -ENOMEM;
 		printk(KERN_ERR PFX "No memory for ib_mad_local_private\n");
@@ -860,9 +856,7 @@ int ib_post_send_mad(struct ib_mad_agent
 		}
 
 		/* Allocate MAD send WR tracking structure */
-		mad_send_wr = kmalloc(sizeof *mad_send_wr,
-				      (in_atomic() || irqs_disabled()) ?
-				      GFP_ATOMIC : GFP_KERNEL);
+		mad_send_wr = kmalloc(sizeof *mad_send_wr, GFP_ATOMIC);
 		if (!mad_send_wr) {
 			printk(KERN_ERR PFX "No memory for "
 			       "ib_mad_send_wr_private\n");



More information about the general mailing list