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");
_______________________________________________
openib-general mailing list
[email protected]
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
