I think I spotted a bug. If these are events from the event queue, then
the event handling queue limit wasn't working. The attached patch will
fix that problem. Can you test this and get back to me?
-Corey
martin rogers wrote:
> Corey Minyard wrote:
>
>> martin rogers wrote:
>>
>>
>>
>>> Corey Minyard wrote:
>>>
>>>
>>>
>>>> I don't know of any leak. Those things are counted and checked at
>>>> module unload time. If you unload the ipmi_msghandler module, it
>>>> should
>>>> give you some idea if there's a leak.
>>>>
>>>> -Corey
>>>>
>>>>
>>>>
>>>
>>> No such luck -it prints nothing.
>>> Lots of memory free after unloading though...
>>>
>>
>>
>> Maybe you are sending lots of messages and not receiving the responses
>> and not closing the fd? Maybe killing a process frees the memory? There
>> are no limits on the receive queue, but the queues will be cleaned up
>> when you close fds.
>>
>>
> No fds- this is all in kernel space. My kernel module is calling the
> OpenIPMI
> kernel module's ipmi_smi_msg_received() function.
>
>>
>>
>>> I'm not worried about ipmi_msghandler freeing pointers, passed to it by
>>> ipmi_smi_msg_received(), when it's unloaded; I'm wondering what frees
>>> this
>>> memory during normal opreation.
>>>
>>> Where do msgs go that are passed in by ipmi_smi_msg_received() ?
>>>
>>
>>
>> The upper layer handling should free the message. For instance, in
>> ipmi_devintf (the user interface), the receive handler throws it into a
>> queue and ioctl that reads the message will pull it from the queue free
>> it (look for ipmi_free_recv_msg).
>>
>>
> Sounds like what I suspect- no user space program is doing the
> necessary accesses
> into OpenIPMI userspace library to free the msgs.
> I just wish I knew of one I could use to test my theory, because
> hpiel/hpigetevents
> don't seem to affect memory usage.
>
> Martin
>
>> -Corey
>>
>>
>>
>>> Martin Rogers
>>>
>>>
>>>
>>>
>>>> martin rogers wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> All,
>>>>>
>>>>> I have a kernel module that is calling into OpenIPMI, and memory is
>>>>> being consumed (kmalloc'd) without being freed.
>>>>>
>>>>> I'm wondering what API, if any, might be involved in freeing the
>>>>> memory
>>>>> being allocated.
>>>>>
>>>>> Without going into too much detail, we do:
>>>>>
>>>>>
>>>>> struct ipmi_smi_msg smiMsg = ipmi_alloc_smi_msg();
>>>>>
>>>>> .. fill in some stuff in smiMsg...
>>>>>
>>>>> ipmi_smi_msg_received(smi_intf, smiMsg);
>>>>>
>>>>> where smi_intf was gotten from ipmi_register_smi(...).
>>>>>
>>>>>
>>>>> The only user space programs we're running are hpiel/hpigetevents,
>>>>> and
>>>>> these
>>>>> don't seem to free the memory allocated by ipmi_alloc_smi_msg().
>>>>>
>>>>> Is there a userspace API that consumes the memory kmalloc'd by
>>>>> ipmi_alloc_smi_msg/ipmi_smi_msg_received ?
>>>>>
>>>>> I don't know what ipmi_smi_msg_received does, so I'm lost..
>>>>>
>>>>> Thanks in advance for any help or pointers...
>>>>>
>>>>> Using OpenIpmi 1.3.18, kernel 2.6.10.
>>>>>
>>>>> Martin Rogers
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>
>>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting
> language
> that extends applications into web and mobile media. Attend the live
> webcast
> and join the prime developer group breaking into this new coding
> territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Openipmi-developer mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/openipmi-developer
The event handler mechanism in the IPMI driver had a limit on the
number of received events, but the counts were not being updated.
Update the counts to impose a limit.
Index: linux-2.6.16/drivers/char/ipmi/ipmi_msghandler.c
===================================================================
--- linux-2.6.16.orig/drivers/char/ipmi/ipmi_msghandler.c
+++ linux-2.6.16/drivers/char/ipmi/ipmi_msghandler.c
@@ -941,6 +941,7 @@ int ipmi_set_gets_events(ipmi_user_t use
list_del(&msg->link);
list_add_tail(&msg->link, &msgs);
}
+ intf->waiting_events_count = 0;
}
/* Hold the events lock while doing this to preserve order. */
@@ -2917,6 +2918,7 @@ static int handle_read_event_rsp(ipmi_sm
copy_event_into_recv_msg(recv_msg, msg);
list_add_tail(&(recv_msg->link), &(intf->waiting_events));
+ intf->waiting_events_count++;
} else {
/* There's too many things in the queue, discard this
message. */
