The flight recoder doesn't handle a 0 byte allocation properly
and it would fail miserably by allocating a single PAGE_SIZE
to handle the logging. That means an enormous performance hit
because of the constant wrapping around the buffer.
If any requested buffer is < 64000 bytes, then force to at least
64000.
In future we will be able to handle small buffers properly, but
for now enable a simple workaround to protect us and the user.
git-svn-id: http://svn.fedorahosted.org/svn/corosync/trunk@2256 fd59a12c-fef9-0310-b244-a6a79926bd2f
The flight recoder buffer size as specified in LOGSYS_DECLARE_SYSTEM
or _logsys_rec_init was expressed in number of ints. A developer asking
to allocate 512K would get a 2M allocation on a machine with sizeof(int) = 4.
This is confusing and the patch addresses it:
- rename rec_size to fltsize for external API (no type change),
because rec_size is used many times internally for other reasons
and it can be confusing.
- rename size to fltsize in _logsys_rec_init.
- document what we allocate and why.
- swap comments around to match the code.
- introduce a simple macro to perform rounding (stolen from linux-2.6.git).
- start shaping fdata header to better handle dynamic values:
* write the flt_data_size as first unsigned int the header.
* change corosync-fplay to read the value and alloc the right amount
of memory instead of hardcoding it again.
git-svn-id: http://svn.fedorahosted.org/svn/corosync/trunk@2255 fd59a12c-fef9-0310-b244-a6a79926bd2f
most of the values in logsys.h are very useful for non logsys library
API users.
Allow to import them without sucking the whole lib.
git-svn-id: http://svn.fedorahosted.org/svn/corosync/trunk@2248 fd59a12c-fef9-0310-b244-a6a79926bd2f
LOGSYS_LEVEL_SECURITY is specific to corosync/openais and it
is used only in the totem configuration.
Drop the special case from logsys that's meant to be a generic
logging library and specify the correct equivalent for totem config.
git-svn-id: http://svn.fedorahosted.org/svn/corosync/trunk@2245 fd59a12c-fef9-0310-b244-a6a79926bd2f
In LCR, global variable g_component_handle is used to keep handle of loaded
component. If this variable has magic value (0xFFFFFFFF) it means,
"we loaded library, but that library doesn't have any component_register
call -> don't try to destroy interfaces list).
If this variable has other value, it means "we loaded library, it registers,
but it exports some interface, what we currently don't need, so we can delete
that handle from libraries/interfaces list" and variable is set to magic value,
or "we loaded library, it registers and exports what we need -> great return some
nice value", but nobody resets variable to it's magic value.
Sadly, if you have loaded some component (needed), then try to load component,
which don't have component_register function, previously loaded component handle
is destroyed.
This problem happened to clm and quorum services, and cause, that loaded
clm handle was destroyed, so EVT (which need clm) just falls.
git-svn-id: http://svn.fedorahosted.org/svn/corosync/trunk@2234 fd59a12c-fef9-0310-b244-a6a79926bd2f
This is needed as the objdb order will change as modules are loaded/unloaded and is
also set up to unload non-default services last (which is the opposite of what
something like Pacemaker needs).
In the worst case, the current behavior leads to cluster services (dlm, ocfs2, etc)
failing during shutdown. This patch also ensures that if, for example, cpg is unloaded
then anything that depends on it is unloaded first.
git-svn-id: http://svn.fedorahosted.org/svn/corosync/trunk@2224 fd59a12c-fef9-0310-b244-a6a79926bd2f
This could probably be more tidy to detect those OS platforms which don't do this instead of hardcoding
to a specific platform we intend to port to.
git-svn-id: http://svn.fedorahosted.org/svn/corosync/trunk@2221 fd59a12c-fef9-0310-b244-a6a79926bd2f
