Note this is only for file targets not stderr or syslog.
https://bugzilla.redhat.com/show_bug.cgi?id=789925
Signed-off-by: Angus Salkeld <asalkeld@redhat.com>
Reviewed-by: Fabio M. Di Nitto <fdinitto@redhat.com>
Our preferred shared logging system is exported via the libqb library. As
a result, the corosync project no longer needs to export logsys.so and the
code can be directly included in the binary. The header file can also be
removed.
Signed-off-by: Steven Dake <sdake@redhat.com>
Reviewed-by: Jan Friesse <jfriesse@redhat.com>
Spinlocks are now removed, because even spinlock can improve
speed is some special cases, in most cases it makes corosync CPU usage
much more intensive and less responsive then if only mutexes are used.
What we were doing is:
pthread_mutex_lock
pthread_spin_lock
pthread_spin_unlock
pthread_mutex_unlock
what is not safe.
Signed-off-by: Jan Friesse <jfriesse@redhat.com>
Reviewed-by: Steven Dake <sdake@redhat.com>
From the strcpy(3) man page, the following warning is given:
The strncpy() function is similar, except that at most n bytes of src
are copied. Warning: If there is no null byte among the first n bytes
of src, the string placed in dest will not be null-terminated.
The current corosync code base does not take this warning into account
when using strncpy, potentially resulting in non-null terminated strings.
Signed-off-by: Russell Bryant <russell@russellbryant.net>
Reviewed-by: Steven Dake <sdake@redhat.com>
Data needs to be locked, otherwise resulting fdata file may be
incorrect.
Signed-off-by: Jan Friesse <jfriesse@redhat.com>
Reviewed-by: Steven Dake <sdake@redhat.com>
'dump_subsys_config()' which is is turn used by the static function
'dump_full_config()' which is never used.
Are these functions used by someone using some magic? I did not find
any reference and even the flag LOGSYS_DEBUG, which prevents them from
compiling, does not exist at some other point.
If these functions are really not used, please remove them (because at
least one of them has a buffer overflow). Patch against 1.2.3
is attached.
If there is a need for these functions, I'll send a patch to fix
the 'decode_mode()' function.
Kind regards
Andreas Florath
Signed-off-by: Andreas Florath <gnu4u at flonatel dot org>
git-svn-id: http://svn.fedorahosted.org/svn/corosync/trunk@2915 fd59a12c-fef9-0310-b244-a6a79926bd2f
we had some __attribute__((__noreturn__))
and some __attribute__((noreturn))
I made them all: __attribute__((noreturn))
git-svn-id: http://svn.fedorahosted.org/svn/corosync/trunk@2853 fd59a12c-fef9-0310-b244-a6a79926bd2f
- Memset for res_setup variable in coroipcs:req_setup_send
- Two memset in logsys for buffers
- Problem in corosync_totem_stats_updater where avg_token_holdtime has
size of avg_backlog_calc
- corosync_totem_stats_init where avg_backlog_calc is 32 bits (not 64)
- objdb problem if new_valie_len != object->value_len. In such case
newly allocated memory is not initialized and in some situations,
value_len is not updated.
git-svn-id: http://svn.fedorahosted.org/svn/corosync/trunk@2787 fd59a12c-fef9-0310-b244-a6a79926bd2f
In logsys there are a number of XYZ_unlocked() functions that are called
like this:
pthread_mutex_lock (&logsys_config_mutex);
XYZ_unlocked();
pthread_mutex_unlock (&logsys_config_mutex);
The XYZ_unlocked() functions should not do any (un)locking.
But _logsys_config_subsys_get_unlocked() unlocks if it finds the subsys.
This means that there is 1 lock and 2 unlocks.
git-svn-id: http://svn.fedorahosted.org/svn/corosync/trunk@2404 fd59a12c-fef9-0310-b244-a6a79926bd2f
logsys_thread_priority_set expects that wthread is already running
but doesn't perform any check if it is.
if logsys_thread_priority_set is invoked before forking the thread,
a segfault is guaranteed.
this changes to logsys_thread_priority_set ensure that a request
for a new scheduler priority is queued if the wthread is not
created yet and the new scheduler parameters are applied as early
as possible after the thread is created.
At the same time:
- add a few comments on clean up that needs to be done
- remove a redundant check for policy != SCHED_OTHER as that's
corosync need specific. logsys should simply accept the request
and apply it.
git-svn-id: http://svn.fedorahosted.org/svn/corosync/trunk@2382 fd59a12c-fef9-0310-b244-a6a79926bd2f
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
