From: Steve Wise <swise@opengridcomputing.com>
To: Bob Sharp <bsharp@NetEffect.com>
Cc: openib-general <openib-general@openib.org>,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Subject: RE: [openib-general] [PATCH v2 1/7] AMSO1100 Low Level Driver.
Date: Thu, 15 Jun 2006 09:03:31 -0500 [thread overview]
Message-ID: <1150380211.22603.17.camel@stevo-desktop> (raw)
In-Reply-To: <1150378863.22603.12.camel@stevo-desktop>
On Thu, 2006-06-15 at 08:41 -0500, Steve Wise wrote:
> On Wed, 2006-06-14 at 20:35 -0500, Bob Sharp wrote:
>
> > > +void c2_ae_event(struct c2_dev *c2dev, u32 mq_index)
> > > +{
> > > +
>
> <snip>
>
> > > + case C2_RES_IND_EP:{
> > > +
> > > + struct c2wr_ae_connection_request *req =
> > > + &wr->ae.ae_connection_request;
> > > + struct iw_cm_id *cm_id =
> > > + (struct iw_cm_id *)resource_user_context;
> > > +
> > > + pr_debug("C2_RES_IND_EP event_id=%d\n", event_id);
> > > + if (event_id != CCAE_CONNECTION_REQUEST) {
> > > + pr_debug("%s: Invalid event_id: %d\n",
> > > + __FUNCTION__, event_id);
> > > + break;
> > > + }
> > > + cm_event.event = IW_CM_EVENT_CONNECT_REQUEST;
> > > + cm_event.provider_data = (void*)(unsigned
> > long)req->cr_handle;
> > > + cm_event.local_addr.sin_addr.s_addr = req->laddr;
> > > + cm_event.remote_addr.sin_addr.s_addr = req->raddr;
> > > + cm_event.local_addr.sin_port = req->lport;
> > > + cm_event.remote_addr.sin_port = req->rport;
> > > + cm_event.private_data_len =
> > > + be32_to_cpu(req->private_data_length);
> > > +
> > > + if (cm_event.private_data_len) {
> >
> >
> > It looks to me as if pdata is leaking here since it is not tracked and
> > the upper layers do not free it. Also, if pdata is freed after the call
> > to cm_id->event_handler returns, it exposes an issue in user space where
> > the private data is garbage. I suspect the iwarp cm should be copying
> > this data before it returns.
> >
>
> Good catch.
>
> Yes, I think the IWCM should copy the private data in the upcall. If it
> does, then the amso driver doesn't need to kmalloc()/copy at all. It
> can pass a ptr to its MQ entry directly...
>
Now that I've looked more into this, I'm not sure there's a simple way
for the IWCM to copy the pdata on the upcall. Currently, the IWCM's
event upcall, cm_event_handler(), simply queues the work for processing
on a workqueue thread. So there's no per-event logic at all there.
Lemme think on this more. Stay tuned.
Either way, the amso driver has a memory leak...
Steve.
next prev parent reply other threads:[~2006-06-15 14:03 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <5E701717F2B2ED4EA60F87C8AA57B7CC05D4E2D8@venom2>
2006-06-15 13:41 ` [openib-general] [PATCH v2 1/7] AMSO1100 Low Level Driver Steve Wise
2006-06-15 14:03 ` Steve Wise [this message]
2006-06-15 21:45 Caitlin Bestler
2006-06-15 21:58 ` Steve Wise
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1150380211.22603.17.camel@stevo-desktop \
--to=swise@opengridcomputing.com \
--cc=bsharp@NetEffect.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=openib-general@openib.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox