| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Older versions of cmake needs to have absolute path in the destination
paremeter of configure_file command.
|
|
|
|
| |
Updated copyright years to include new year 2014.
|
|
|
|
| |
This patch removes trailing spaces from source files.
|
|
|
|
|
| |
The previous commit b915ee1ef9a4ebe bumped minor version number instead
of major one that is more suitable for symbol hiding case.
|
| |
|
|
|
|
|
|
| |
The commit c98f09a865f1b made some exported symbols hidden which can be
considered an ABI break. Let's bump the library soname version to indicate
a stable ABI for now.
|
|
|
|
|
|
| |
- annotate functions that are supposed to be called with mutex held
- mark functions static if not exported public
- remove unused declarations
|
|
|
|
|
|
|
|
|
| |
Accomplished that by registering a pthread cleanup handler that gets
called on thread cancellation as well as on normal exit.
A minor code shuffle had to be done since the cleanup handlers are macros
in fact and no control flow commands (return, continue) should be called
within.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The approach introduced in commit 381f4038a6a was on a good way however
turned out the pthread_cancel() actually queues a cancellation request
since we're using deferred cancellation mode and continues the code flow
until a function that is a cancellation point is called. We unlocked
the mutex before joining the thread which led to mutex acquisition by
the thread and then cancelling on a syscall, leaving the mutex locked
forever.
Having cancellation and join with mutex held was not a solution as it
would make the thread waiting for mutex leading to deadlock.
Instead, this patch introduces a private flag that will indicate the
thread should cancel itself. Two scenarios are possible:
- the thread is doing unlocked stuff, typically waiting for events
using syscalls that are cancellation points. In this case the
pthread_cancel() will take effect immediately, breaking the syscall
and quitting the thread. We're still in unlocked state.
- the thread is holding the lock, in that case the im_stop_ind() will
wait until that work is finished. It's better to leave the manage
thread finish its job, it's mostly CMPI stuff and breaking in the
middle would leak some memory. Once the main thread acquires the
mutex, it cancels the thread, sets a private flag and unlocks again.
While waiting for thread join is finished, the thread picks up the
lock again as it was waiting for it and as a first thing it will
check the private flag and quits gracefully, unlocking the mutex.
As a side effect, the pthread cancellation machinery has no chance
to kick in as there was no cancellation point on the way.
|
|
|
|
| |
Blame me, commit 52cdb2a9c497
|
|
|
|
| |
As pointed out by scanbot :).
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the indication manager thread was stopped, it destroys its mutex and
creates new one. If pthread_mutex_destroy() fails because the mutex is
locked, the new mutex is not created -> the old one is used, but it's already
locked -> deadlock.
So let's make sure the thread does not hold the mutex when destroying the thread.
Rewrite of indication manager thread is needed to have the manage() function
interruptible when waiting for events, e.g. using a pipe and select(),
this pthread_cancel leads to memory leaks.
|
| |
|
|
|
|
| |
Reading the code, it seems there's something missing...
|
|
|
|
|
|
|
|
|
|
|
| |
Creating mutexes with the PTHREAD_MUTEX_ERRORCHECK attribute proved to be
a wrong way. It turned out locking was not working properly as any attempt
to lock already locked mutex failed with a return value that we didn't check.
The only reason we were using this special attribute was to prevent crash on
forcefully unlocking mutex in an unknown state. That didn't work either as long
as EPERM was returned when trying to unlock the mutex that has been locked from
other thread... that was forcefully canceled. That only led to deadlocks
fortunately hard to hit, unfortunately equally hard to debug.
|
|
|
|
| |
A small copy-paste error from commit cb1ffc827
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Indications are often started on CIMOM startup if there are some registered
persistently (or failed their cleanup). This will start several indication
managers as needed. When a new filter is registered, it needs initial values
for polling mode. This is normally done on manage thread iteration but in this
case, when indication manager is already running, it doesn't get filled and
any change event will go unnoticed since we don't have anything to compare
new values against.
This change will immediately fill actual values for newly added filters
in case indications have been already started.
|
|
|
|
|
|
|
|
|
|
|
| |
The filter checker code was kinda duplicate across providers and no special
plans have been made for it. This change makes passing a filter checker callback
during indication manager creation no longer mandatory and default filter
checker will be used when NULL. However, the list of acceptable classes need
to be registered before first use.
This change also brings greater flexibility of the filter query which may now
consist of multiple limit conditions.
|
|
|
|
| |
Fix for a random crash triggered by malformed select expression.
|
|
|
|
| |
This ideally shouldn't happen in well writen providers.
|
|
|
|
|
|
| |
When the watcher() callback returns unsuccessfully and gather() part
has not been run, we may end up with NULL enums that have been originally
created by add_enumeration(). This prevents segfault in such case.
|
|
|
|
|
|
|
|
|
| |
Can't really have global variables for threads and mutexes as long
as there are more indication managers running, simultaneously using
the same objects, leading to deadlock in a matter of time.
This patch moves the pthread stuff in the IMManager struct which is
(usually) speficic to each CIM indication class.
|
|
|
|
|
|
|
|
|
|
|
| |
Things are bit harsh in the indication manager when it comes to cancellation.
At certain situation we force-cancel the polling thread, having no chance
for cleanup. The mutex we use to protect memory shared between threads may
be left in undefined state.
The pthread_mutex_unlock() call in im_stop_ind() may be called on already
unlocked mutex which, in default setup, causes a segfault. Setting a mutex
attribute PTHREAD_MUTEX_ERRORCHECK will prevent this, returning proper error.
|
|
|
|
|
|
|
|
|
|
| |
As per https://fedorahosted.org/openlmi/wiki/CodingConventions any
debugging message that shouldn't go to user should be using
CMTraceMessage().
Doing this change to minimize output to syslog, making journald
indications nearly impossible to debug due to constant logging,
generating more and more indications, resulting in endless loop.
|
|
|
|
|
| |
This fixes thread leak due to im_stop_ind() not cleaning up running thread.
This change also brings some guarantees, see README for details.
|
|
|
|
|
|
| |
When not polling, manager->enums is NULL resulting in segfault. This patch
adds extra test and retrieves the object path required from instances
to be sent.
|
|
|
|
|
| |
Manual instance creation in the gather callback sometimes requires access
to the CMPIBroker instance, stored in the indication manager struct.
|
| |
|
| |
|
|
|
|
| |
Signed-off-by: Roman Rakus <rrakus@redhat.com>
|
|
|
|
|
|
|
| |
When some filter is added there was missing very first poll
leading in loosing of first indication.
Signed-off-by: Roman Rakus <rrakus@redhat.com>
|
| |
|
|
|
|
| |
Signed-off-by: Roman Rakus <rrakus@redhat.com>
|
|
Signed-off-by: Roman Rakus <rrakus@redhat.com>
|