[ofw] [ofw'[Patch][umad] Avoid dangling reference

Hefty, Sean sean.hefty at intel.com
Mon Apr 4 12:49:11 PDT 2011


> > --- umad.cpp      (revision 7570)
> >
> > +++ umad.cpp   (revision 7571)
> >
> > @@ -613,11 +613,11 @@
> >
> >
> >
> >                 umad_convert_addr(&mad->addr, &((WM_MAD *) mad)->Address);
> >
> >                 hr = ports[portid].prov->Send((WM_MAD *) mad, NULL);
> >
> > -              umad_convert_av(&((WM_MAD *) mad)->Address, &mad->addr);
> >
> >                 if (FAILED(hr)) {
> >
> >                                 _set_errno(EIO);
> >
> >                                 return GetLastError();
> >
> >                 }
> >
> > +             umad_convert_av(&((WM_MAD *) mad)->Address, &mad->addr);
> 
> There is something else wrong here, possibly in the upper layer.  The caller is freeing the memory
> referenced by the *umad parameter while the umad_send() call is still operating on it.  They could
> just as easily free the *umad memory in the success case.
> 
> It looks like the caller may be using an event to indicate that umad_send() is done with the buffer,
> which is not the case.  If you have full details on what's happening, we may want to bring this up
> with the opensm maintainer to make sure that we have the right solution.

I haven't seen any response yet, possibly because of the ofa conference.  We need a different 'fix' for this.  The easiest thing to do is to copy the user's input buffer into a new one and call umad_convert_addr on that buffer.  That would remove the need to call umad_convert_av.  This is obviously less efficient, since we need to copy the buffer, but it would fix the issue and work with the existing kernel.  There's an implicit assumption that umad_send() will not touch the user's buffer again after the underlying file write call has been invoked.

- Sean



More information about the ofw mailing list