[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