* RE: [openib-general] [PATCH v2 1/7] AMSO1100 Low Level Driver.
@ 2006-06-15 21:45 Caitlin Bestler
2006-06-15 21:58 ` Steve Wise
0 siblings, 1 reply; 4+ messages in thread
From: Caitlin Bestler @ 2006-06-15 21:45 UTC (permalink / raw)
To: Steve Wise, Bob Sharp; +Cc: openib-general, linux-kernel, netdev
netdev-owner@vger.kernel.org wrote:
> 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...
>
Having the IWCM copy the pdata during the upcall also leaves
the greatest flexibility for the driver on how/where the pdata
is captured. The IWCM has to deal with user-mode, indefinite
delays waiting for a response and user-mode processes that die
while holding a connection request. So it makes sense for that
layer to do the allocating and copying.
^ permalink raw reply [flat|nested] 4+ messages in thread* RE: [openib-general] [PATCH v2 1/7] AMSO1100 Low Level Driver.
2006-06-15 21:45 [openib-general] [PATCH v2 1/7] AMSO1100 Low Level Driver Caitlin Bestler
@ 2006-06-15 21:58 ` Steve Wise
0 siblings, 0 replies; 4+ messages in thread
From: Steve Wise @ 2006-06-15 21:58 UTC (permalink / raw)
To: Caitlin Bestler; +Cc: Bob Sharp, openib-general, linux-kernel, netdev
> > 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...
> >
>
> Having the IWCM copy the pdata during the upcall also leaves
> the greatest flexibility for the driver on how/where the pdata
> is captured. The IWCM has to deal with user-mode, indefinite
> delays waiting for a response and user-mode processes that die
> while holding a connection request. So it makes sense for that
> layer to do the allocating and copying.
I've already coded and test this. The IWCM will copy the pdata...
Steve.
^ permalink raw reply [flat|nested] 4+ messages in thread
[parent not found: <5E701717F2B2ED4EA60F87C8AA57B7CC05D4E2D8@venom2>]
* RE: [openib-general] [PATCH v2 1/7] AMSO1100 Low Level Driver.
[not found] <5E701717F2B2ED4EA60F87C8AA57B7CC05D4E2D8@venom2>
@ 2006-06-15 13:41 ` Steve Wise
2006-06-15 14:03 ` Steve Wise
0 siblings, 1 reply; 4+ messages in thread
From: Steve Wise @ 2006-06-15 13:41 UTC (permalink / raw)
To: Bob Sharp; +Cc: openib-general, linux-kernel, netdev
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...
Thanks,
Steve.
^ permalink raw reply [flat|nested] 4+ messages in thread* RE: [openib-general] [PATCH v2 1/7] AMSO1100 Low Level Driver.
2006-06-15 13:41 ` Steve Wise
@ 2006-06-15 14:03 ` Steve Wise
0 siblings, 0 replies; 4+ messages in thread
From: Steve Wise @ 2006-06-15 14:03 UTC (permalink / raw)
To: Bob Sharp; +Cc: openib-general, linux-kernel, netdev
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2006-06-15 21:58 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-06-15 21:45 [openib-general] [PATCH v2 1/7] AMSO1100 Low Level Driver Caitlin Bestler
2006-06-15 21:58 ` Steve Wise
[not found] <5E701717F2B2ED4EA60F87C8AA57B7CC05D4E2D8@venom2>
2006-06-15 13:41 ` Steve Wise
2006-06-15 14:03 ` Steve Wise
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox