On Tue, 2005-03-29 at 19:05, Sean Hefty wrote: > Libor Michalek wrote: > > >>With this patch, changing the kmalloc in cm_alloc_msg() to use > >>GFP_ATOMIC rather than GFP_KERNEL should allow the CM to be usable from > >>interrupt context. Of course, I haven't actually tested this... > >> > >>I have no objection to this change however. > > > > I could go either way on this issue myself. If the call can only be > > made from thread context I will use schedule_work() to execute the > > request to send the dreq. However, I would imagine that other CM users > > would want to send requests in interrupt context... > > My intention was that the CM should be able to match the calling > conventions of underlying verbs/mad layer routines, except for the > destroy_cm_id call that may block. It should be easy enough to at > least test whether the code works at interrupt with these changes, and > if not, then call schedule_work until we can identify why not and see > if other changes can be made to support it.
Is this just the kmalloc in cm_alloc_msg or is there more to this ? One other comment/question about cm_alloc_msg: It seems possible that this is called prior to cm_id_priv->av.port being initialized. Should an error be returned for this case ? A follow on to this: Doing so appears to cause the connection to go into timewait. Is that correct for these cases ? Not sure what else can be done (perhaps error ?) -- Hal _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
