Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>: > Subject: Re: [Andrew Morton] inappropriate use of in_atomic() > > On Thu, 2005-03-10 at 23:50, Roland Dreier wrote: > > 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. > > That could be bad if this persists but I suppose there are other ill > effects of this. > > > 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... > > There aren't that many places this is called. Also, it appears to me > that sa_query.c is already doing this for some of it's memory allocation > and this could be passed down to ib_post_send_mad. > > int ib_sa_path_rec_get(struct ib_device *device, u8 port_num, > struct ib_sa_path_rec *rec, > ib_sa_comp_mask comp_mask, > int timeout_ms, int gfp_mask, > ... > > This approach seems better to me from a robustness standpoint. > > Is the difficulty determing what to set the mask to for each call ? If > they all end up being GFP_ATOMIC, this reduces to your preferred > solution. > > The biggest impact appears to be on CM (at least currently).
As far as I remember most CM code is thread level anyway, isnt it? -- MST - Michael S. Tsirkin _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
