[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