Avoid a race condition that could lead to a segmentation fault.
authorTobias Brunner <tobias@strongswan.org>
Thu, 25 Feb 2010 07:56:05 +0000 (08:56 +0100)
committerTobias Brunner <tobias@strongswan.org>
Thu, 25 Feb 2010 08:26:16 +0000 (09:26 +0100)
commit608af0a44564606dc3d10c59e110e9b3a7e08e97
treef5fe2587bb3a4806ad65edf14e3a321a687b14c4
parent3e35a6e7a1b01f53f75c6020184845c3129db1ac
Avoid a race condition that could lead to a segmentation fault.

Let's assume the callback function of a callback job returns
JOB_REQUEUE_FAIR in one call and JOB_REQUEUE_NONE in the next. Before
this fix, the thread executing the callback job would requeue the job
before unregistering itself. If there was a context switch right after
the job got requeued, and if the thread that requeued the job never got
resumed until a second thread executed the job and, due to the return
value of JOB_REQUEUE_NONE, destroyed it, then when the first thread
eventually got resumed and tried to lock the mutex to unregister itself
the pointer wouldn't be valid anymore, thus resulting in a segmentation fault.
src/charon/processing/jobs/callback_job.c