Corey Minyard wrote:
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?
Sure.
FYI, my call to ipmi_register_smi(...) looks like:
rc = ipmi_register_smi(&vmc_smi_handlers, NULL ...etc...);
where vmc_smi_handlers is defined as:
static struct ipmi_smi_handlers vmc_smi_handlers =
{
.owner = THIS_MODULE,
.sender = sender,
.request_events = request_events,
.set_run_to_completion = set_run_to_completion,
};
and where set_run_to_completion and request_events do nothing, and
sender....ends up calling ipmi_smi_msg_received again....don't ask me,
I didn't write it.
Martin
-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. */
-------------------------------------------------------
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
