github/open-cas-linux
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Free thread memory after it is stopped.

Browse Source 
After marking thread as ready to stop, CAS was waiting this for thread to exit
out of main execution loop (in _cas_io_queue_thread()). In case of management
queue it lead to deadlock because both stoping queue and main execution loop was
performed in the same execution context.

Since freeing memory is the only operation after stopping thread, it can be
moved just after the main thread loop. After this little reordering,
synchronising between _cas_stop_thread() and _cas_io_queue_thread() in no longer
needed, and no deadlock will occur.

This change is needed to put management qeueue from completion context. Without
this cachnge, there will be no possiblitiy to stop cache from completion context
and to make rollback.

Signed-off-by: Michal Mielewczyk <michal.mielewczyk@intel.com>
This commit is contained in:
Michal Mielewczyk 2019-12-04 08:51:33 -05:00
parent 3eda503095
commit d483951ebe
1 changed files with 3 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
modules/cas_cache/threads.c
View File

@ -50,9 +50,10 @@ static int _cas_io_queue_thread(void *data)
WARN(ocf_queue_pending_io(q), "Still pending IO requests\n");
/* If we get here, then thread was signalled to terminate.
* So, let's complete and exit.
* So, let's free memory and exit.
*/
complete_and_exit(&info->compl, 0);
printk(KERN_DEBUG "Thread %s stopped\n", info->name);
kfree(info);
return 0;
}
@ -201,13 +202,9 @@ static void _cas_start_thread(struct cas_thread_info *info)
static void _cas_stop_thread(struct cas_thread_info *info)
{
if (info->running && info->thread) {
init_completion(&info->compl);
atomic_set(&info->stop, 1);
wake_up(&info->wq);
wait_for_completion(&info->compl);
printk(KERN_DEBUG "Thread %s stopped\n", info->name);
}
kfree(info);
}
int cas_create_queue_thread(ocf_queue_t q, int cpu)