It looks like the fix above introduces regressions (actually other new bugs):
commit 96f81469ff993b6063bb8829d9b336590510466d
Author: Hannes Reinecke <email address hidden>
Date: Mon May 4 16:46:58 2009 +0200
libmultipath: update waiter handling
The current 'waiter' structure accesses fields which belong
to the main 'mpp' structure, which has a totally different
lifetime. With this patch most of these dependencies are
removed and the 'waiter' structure can run independently
of the main 'mpp' structure, reducing the risk of
use-after-free faults.
Signed-off-by: Hannes Reinecke <email address hidden>
Introduces this problem:
commit c301a3f09203edf91df5a9adf4e32ea2a7238cda
Author: Hannes Reinecke <email address hidden>
Date: Wed May 25 14:40:19 2011 +0200
Race condition when calling stop_waiter_thread()
We cannot access the waiter structure from other threads as
the lifetime is totally different and it might be deleted
at any time.
So we better store the pthread id in the calling thread and
just send a signal to the thread.
References: bnc#642846
Signed-off-by: Hannes Reinecke <email address hidden>
It looks like the fix above introduces regressions (actually other new bugs):
commit 96f81469ff993b6 063bb8829d9b336 590510466d
Author: Hannes Reinecke <email address hidden>
Date: Mon May 4 16:46:58 2009 +0200
libmultipath: update waiter handling
The current 'waiter' structure accesses fields which belong
to the main 'mpp' structure, which has a totally different
lifetime. With this patch most of these dependencies are
removed and the 'waiter' structure can run independently
of the main 'mpp' structure, reducing the risk of
use-after-free faults.
Signed-off-by: Hannes Reinecke <email address hidden>
Introduces this problem:
commit c301a3f09203edf 91df5a9adf4e32e a2a7238cda
Author: Hannes Reinecke <email address hidden>
Date: Wed May 25 14:40:19 2011 +0200
Race condition when calling stop_waiter_ thread( )
We cannot access the waiter structure from other threads as
the lifetime is totally different and it might be deleted
at any time.
So we better store the pthread id in the calling thread and
just send a signal to the thread.
References: bnc#642846
Signed-off-by: Hannes Reinecke <email address hidden>