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

Roland Dreier roland at topspin.com
Thu Mar 10 20:50:27 PST 2005


drivers/infiniband/core/mad.c is in Andrew's list...

>From looking at the code, the best fix I can come up with is just to
always use GFP_ATOMIC ... worst case we drop a MAD under memory
pressure.  The other option is to change ib_post_send_mad() to take a
GFP_ mask as a parameter, but that doesn't seem worth doing...

--- 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");



-------------- next part --------------
An embedded message was scrubbed...
From: Andrew Morton <akpm at osdl.org>
Subject: inappropriate use of in_atomic()
Date: Thu, 10 Mar 2005 20:40:06 -0800
Size: 3123
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20050310/87dec718/attachment.mht>


More information about the general mailing list